Verdict: ChaosBSD
Scrap hardware. No fear. You said, out loud, that you would write the driver yourself.
Let us review your answers. You picked the machine the vendor was sending to the smelter. When asked about a missing driver, you reached for the datasheet. You were not choosing an operating system. You were choosing a victim. This is not a choice the installation software likes. But it is an honest one.
What you get
Section titled “What you get”- ChaosBSD 16-QUANTUM: FreeBSD 16 as the base, anything sane from Phabricator cherry picked, plus every driver too broken, too incomplete, or too speculative for upstream to accept. Drivers for hardware that should not exist but does. Reverse-engineered support for Apple firmware. USB quirks for devices that lie about their state.
- Hardware that was headed to the aluminum smelter in 2026 getting a second life as a functional machine again. A 2015 MacBook. A discarded Panasonic Toughbook. Machines the software gave up on before the hardware did.
- The full experience: magic numbers in firmware, undocumented SMC keys, iGPU vs dGPU power negotiation through ACPI spoofing, and the deep satisfaction of the first successful
kldloadon hardware the upstream maintainers said was impossible. - Upstream FreeBSD patches for real machines that hadn’t seen driver work in 24 years. Your experiments matter. Your fixes matter. You are not just rescuing hardware, you are contributing to the ecosystem.
What will hurt
Section titled “What will hurt”- Everything. That is the point. If it boots, that is a bonus, not a guarantee. You are not here for stability. You are here for understanding.
- There is no community to ask, because you are the community. There are no FAQ sections for your weird hardware combo. You are the first. You will solve it yourself or contribute the solution.
- Breaking things is part of the process. A bad patch can brick the SMC. A wrong ACPI setting can disable your GPU. You read the code. You understand the risks. You accept them.
- Patience. Debugging a driver for hardware the vendor won’t document takes time. Weeks. Months sometimes.
Getting help
Section titled “Getting help”- The story - understanding why ChaosBSD exists, the process of reverse-engineering drivers, and the people who have already done this.
- FreeBSD Handbook - the upstream documentation for everything that does work.
- FreeBSD Mailing Lists - questions@ for when you break something.
- Datasheets. The real documentation. On GitHub, on vendor sites, on random forums from 2003. You hunt them.
- Your own capability. The kernel source is the truth. Read it. Understand it. Modify it.
First steps
Section titled “First steps”- Read the story. Really. The entire thing. You need to understand what ChaosBSD is before you try it.
- Check if your hardware is even supported yet. Look at recent FreeBSD driver patches. Is your machine on a list? Has someone else solved this already?
- Get a USB install stick of both FreeBSD 16 and ChaosBSD. Know how to fall back. Know what you are testing.
- Set up a separate development machine. Do not test driver work on your only computer.
- Install git. You will need to fork FreeBSD and create patches. This is not point-and-click work.
Where to start
Section titled “Where to start”Read the story to understand what you are actually signing up for. Then find a warehouse, a dumpster, a recycling pile. Every city has one, full of machines the software gave up on before the hardware did. Build.
This is not a recommendation. This is a diagnosis. And a job description.
Welcome home.