I was reading through the #OpenBSD documentation and ran into a small but revealing detail: in OpenBSD 5.6, released in 2014, the project didn’t merely disable Bluetooth by default it removed the Bluetooth subsystem altogether. The official release page simply lists “bluetooth” among the utilities removed from the base system, while the 5.6 changelog gives the blunt explanation: “bluetooth(4) support removed (code did not work properly anyway).” What I find interesting is that this was not presented as a grand statement that Bluetooth itself was inherently unacceptable or impossible to secure. OpenBSD had carried Bluetooth support before: its historical changelog shows that parts of the #NetBSD Bluetooth stack were imported and that Bluetooth drivers were later added to the generic kernel configuration, though initially not enabled. There was even a driver, ubt(4), for #USB #Bluetooth #adapters in OpenBSD 5.5. So, the practical reason OpenBSD dropped it in 5.6 was much simpler: the code was not working properly, which strongly suggests it had become difficult to maintain and could not meet the project’s expectations for reliability and code quality. Rather than leaving behind a feature that existed mostly on paper, behaved unpredictably, or accumulated unreviewed complexity, the developers chose to remove it. In many systems, keeping a feature can feel safer because users may rely on it someday. OpenBSD often takes the opposite view: unsupported or broken code is not really a feature it is maintenance debt, potential attack surface, and a promise the project cannot honestly keep. Removing it makes the system smaller, easier to audit, and clearer about what actually works. My takeaway from reading this is that OpenBSD 5.6 did not abandon Bluetooth because of a single dramatic vulnerability or because wireless hardware was categorically forbidden. It removed Bluetooth because the implementation was not in a state the project considered worth carrying forward. It is one of those deceptively small release-note lines that reveals a bigger principle: for OpenBSD, a feature has to earn its place through working, maintainable code not merely through demand or familiarity. #openbsd #os #adapter #bluetooth