Quem roda workloads pesados no Linux ou no WSL2 — compilação de projetos grandes em Rust ou C++, containers Docker, inferência de modelos locais — já passou por aquele travamento completo do sistema quando a RAM física esgota e o kernel cai em swap thrashing no disco.

Ao mesmo tempo, olhando no `nvidia-smi`, você vê uma GPU com 6GB ou 8GB de memória GDDR6 ultrarrápida ficando completamente ociosa durante a compilação.

Para resolver isso sem precisar alterar ou recompilar o kernel do host, escrevi o **RamShared**, um driver userspace em Rust que aloca a VRAM ociosa via CUDA Zero-Copy Direct DMA e a expõe para o Linux como um dispositivo de bloco real (`/dev/ublkb0`) utilizando o subsistema `ublk` (Linux 6.0+) e `io_uring`.

---

Benchmarks Reais Medidos com `fio` (4KB Random Read, QD1 no WSL2):

* **Swap em disco VHDX/SSD padrão:** ~2.114 µs (2.1 ms) de latência | ~336 IOPS * **RamShared NBD (VRAM):** ~326 µs de latência | ~9.6k IOPS * **RamShared ublk (io_uring):** **~8 µs** de latência (264x mais rápido / queda de 99.6%) | **~22k+ IOPS** * **Throughput de Leitura Contínua:** **8.53 GB/s** (saturação do barramento PCIe 3.0/4.0 x16).

---

Por que isso faz diferença na prática:

No WSL2, o swap padrão em disco passa por uma cadeia pesada de virtualização: `ext4 -> VHDX -> Hyper-V -> NTFS -> Host SSD`.

Cada page fault síncrono leva mais de 2ms, o que faz a interface e o terminal congelarem inteiros durante picos de memória. Ao desviar esse tráfego diretamente para a VRAM da GPU via PCIe DMA com `ublk`, a latência cai para microsegundos de um dígito (8 µs), eliminando os travamentos e impedindo o kernel OOM Killer de matar a compilação.

---

Proposta Upstream no WSL2 (Microsoft):

Abrimos uma RFC formal diretamente no repositório oficial da Microsoft pro WSL2 propondo suporte nativo a dispositivos de bloco backed por VRAM em máquinas virtuais Hyper-V: 👉 **RFC Issue:** https://github.com/microsoft/WSL/issues/41054

O projeto é 100% Rust, de código aberto: 👉 **GitHub:** https://github.com/emersonbusson/ramshared

Se alguém tiver dúvidas sobre a implementação com `ublk`, `io_uring` em userspace ou tradeoffs de latência via DMA, fico à disposição nos comentários!

I have been reverse-engineering the InsydeH2O firmware used by the Lenovo IdeaPad Gaming 3 15ARH05 (82EY / IP3GAMING-15ARH).

The project started because this model exposes only a very limited BIOS interface, while common unlock sequences such as Fn+R+N do not appear to work reliably on this generation.

So far, I have:

• extracted Lenovo’s official FCCN21WW Windows update package;
• recovered the complete 16 MiB update ROM;
• parsed its AMD PSP directory;
• decompressed and executed the x86 reset-stage image;
• traced its reset loop under QEMU;
• extracted the Setup Utility and reconstructed its IFR;
• confirmed the existence of a separate hidden Advanced form set;
• recovered its GUID, variable stores, offsets and option inventory;
• tested an experimental SREP runtime patch without permanently modifying the firmware.

The hidden menu contains controls for:

• PCIe GPP and power policies;
• SATA/AHCI and RAID configuration;
• TPM and fTPM;
• USB controllers and individual ports;
• ACPI features;
• SVM, SVM Lock and SMM Code Lock;
• DASH and AMD remote KVM;
• Above 4 GB MMIO.

One particularly interesting result is that the Advanced form set is not surrounded by a top-level IFR SuppressIf condition. My current hypothesis is that Lenovo/Insyde hides it through a visibility table or registration logic inside H2OFormBrowserDxe, rather than through a simple “unlock” setup variable.

I also recovered this form-set GUID:

C6D4769E-7F48-4D2A-98E9-87ADCCF35CCC

However, the runtime SREP patch has not exposed the menu yet. The laptop currently runs FCCN19WW, while the analyzed update is FCCN21WW, so differences in modules, patterns or variable semantics may explain the failure.

The repository documents the full process, hashes, extraction commands, QEMU findings, IFR inventory, experimental SREP configuration and suggested next steps:

https://github.com/root-hunter/lenovo_bios

Update: the hidden Advanced BIOS menu has now been successfully unlocked on the test machine using SREP. This is a runtime unlock and does not require flashing a modified BIOS image.

The method remains experimental and model/firmware-specific. Hidden settings can still cause a brick, boot failure or no-display condition, so do not change unfamiliar options without a verified SPI backup and recovery plan.

I would especially appreciate help from anyone who:

• owns the same 15ARH05 / 82EY model and can reproduce the unlock;
• can test it on other FCCN firmware versions;
• has experience with InsydeH2O, SREP or H2OFormBrowserDxe;
• can help validate and document the exposed settings safely.

Issues, corrections and reproducible test results are welcome.

Que mundo é esse em que meu sistema bloqueia eu usar um aplicativo só por que ele está fora de uma loja oficial? Qbittorrent, pelo menos até onde eu saiba, é um dos clientes mais seguros para torrent.

O pior é que eu nem estava usando ele para pirataria, tava querendo baixar uma ISO Linux. Enfim, só uso esse SO por que realmente dependo dele, mas ta fueda.

Já faz alguns anos desde que usei o Ubuntu e, na época, não consegui me acostumar. Nesse período, minha vontade de sair do Windows me levou a aprender Hackintosh, e assim foi: usei do Mac OS X Leopard até o Mac OS X Yosemite.

Depois, me desfiz da minha máquina e comprei um notebook pouco compatível com Hackintosh, então voltei ao Windows. Hoje, após passar raiva mês após mês, resolvi testar Linux em uma partição separada e, aos poucos, fui migrando meu fluxo de trabalho para outros sistemas. Testei CachyOS, Linux Mint (Cinnamon), Fedora, Fedora com KDE, Kubuntu e, por fim, Ubuntu. Meu notebook de trabalho é um LOQ com 16 GB de memória RAM, 1 TB de SSD e uma NVIDIA 4070 com 8 GB de RAM.

Eu tinha problemas de desempenho com a instalação original e, mesmo após formatar e colocar um Windows 11 Pro original, ainda enfrentava lentidão: a placa de vídeo era exigida com quase nada aberto, havia travamentos no Explorer e alguns bugs após atualizações.

Realmente não dá mais para usar esse sistema; os remendos da Microsoft não vão corrigir. Ou lançam um Windows 12, ou vão continuar perdendo espaço. No Ubuntu, tudo flui: consigo fazer o mesmo trabalho de forma leve e rápida, com recursos sobrando para ainda jogar ao mesmo tempo. É realmente incrível.

[KDE Plasma] Clean & Minimalist Monochrom Setup 🖤

Details:

• OS: CachyOS
• DE: KDE Plasma 6
• Theme: Custom Dark Monochrom
• Widgets:
  • Mike TimeStats (Top-left weather & stats)
  • Modern Clock Turkish Edition (Center large clock and Turkish date/day display)
  • PlasMusic Toolbar (Top-right minimalist music player)
  • Activate Linux (Bottom-right meme watermark)

Ja coloquei o mint nessa maquina potente kklkkkkkk

tds as vezes q eu tento rodar essa distro maldita meu pc desiste da vida, e tds as vzs é por conta da maldita atualizaçao do driver nvidia, eu nn sei mais como enfrentar o distro hopping, eu ja testei o cu buntu, ja vi q eu me dou bem nele e msm assim eu simplesmente nn consigo ficar numa distro, eu ja nn sei mais oq fazer🤧🤧

Qual é a frequência necessária de troca de sistema para ser considerado um hopper? 😅

Confesso que não sou de ficar trocando toda hora, alias, troquei muito pouco, a pergunta é mais pela brincadeira e ver a opinião do pessoal.

Peguei um notebook pra formatar, cheguei às 12 horas, falei pro cliente, no máximo 14 horas está liberado.

Desde 13:30 vendo essa tela, que raio de update é este?

Na boa, já havia esquecido que o Windows quando quer é uma bosta.

com o reddit e outros sites nao acontece esse problema mas sempre que tento baixar videos do youtube dá sempre esse problema de resposta