Hacker News Reader

Comment by f1shy | Hacker News Reader

I saw always intel as a HW company making terribly bad SW. Anywhere I saw intel SW I would run away. Lately I used a big open source library from them, which is standard in the embedded space. Work great, but if you look the code you will be puking for a week.

View on HN

In my experience Intel's WiFi and Bluetooth drivers on Linux are, by far, the best. They're reliably available on the latest kernel and they actually work. After having used other brands on Linux, I have no intention of getting non-intel WiFi or Bluetooth any time soon. The one time that I found a bug, emailing them about it got me in direct contact with the developers of the driver.

I had a different non-Intel WiFi card before where the driver literally permanently fried all occupied PCIe slots -- they never worked again and the problem happened right after installing the driver. I don't know how a driver such as this causes that but it looks like it did.

Yes, their open source drivers had a painful birth, but they are good once they're sanded and sharpened with the community.

However, they somehow managed to bork e1000e driver in a way that certain older cards sometimes fail to initialize and require a reboot. I have been bitten by the bug, and the problem was fixed later by reverting the problematic patch in Debian.

I don't know current state of the driver since I passed the system on. Besides a couple of bad patches in their VGA drivers, their cards are reliable and works well.

From my experience, their open source driver quality does not depend on the process, but on specific people and their knowledge and love for what they do.

I don't like the aggressive Intel which undercuts everyone by shady tactics, but I don't want them to wither and die, either, but seems like their process, frequency and performance "tricks" are biting them now.

that's only because their hardware is extremely simple.

so the driver have little to screw up. but they still manage to! for example, the pci cards are all broken, when it's literary the same hardware as the USB ones.

Interesting. Does Bluez fall under that umbrella?

I have found bluez by far the hardest stack to use for Bluetooth Low Energy Peripherals. I have used iOS’s stack, suffered the evolution of the Android stack, used the ACI (ST’s layer), and finally done just straight python to the HCI on pi. Bluez is hands down my least favorite.

The team working on their Realsense depth cameras was doing great work on the SDK, in my opinion.

Frequent releases, GitHub repo with good enough user interaction, examples, bug fixing and feedback.

Reply on news.ycombinator.com