Hacker News new | past | comments | ask | show | jobs | submit login

As someone who spent a bit of time trying to start a project based on the Edison, the most frustrating thing was the amount of bugs and the lack of documentation to be able to do anything about it myself, leaving me hopelessly waiting for them to release fixes.

For example, after several months of terribly slow and buggy SPI and no fix over multiple releases, I finally switched to ARM and am very glad I did. Intel did finally fix the SPI issue about 9 months after it was first reported.

With ARM, I had plenty of issues and challenges, but had the documentation and resources I needed to be able to fix things, as well as a better support community.

One of the key issues in the Intel support communities was a growing lack of trust, now confirmed by Intel dropping out. It takes a big commitment to really understand a system, and the nice thing about ARM is that the community goes beyond a single company, so a company dropping out is not as significant as in this case with Intel.




> lack of documentation

For what it's worth, I think it's an intel trademark to have bad or lacking documentation. Even projects that should have stellar documentation like intel TBB or MKL have fairly cryptic docs


They somehow think "Intel Inside" marketing strategy worked (not that Wintel monopoly happened) and they think that they can just "Intel Inside" their way into any market, and somehow make Wintel-like margins even in b2b markets that are fully commoditized, not need to put out competitive parts or reduce adoption costs with things like documentation.


Indeed. I attempted to do some node.js prototyping (since it was one of the directly-supported environments, supposedly) -- but they never pushed any sort of update, such that one was stuck on a (by node standards) ancient version.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: