Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
How do you figure? At no point in this process is it even necessary to directly engage Intel themselves. The data sheets are published on their website for anyone. The SoC itself is available from Mouser.May be I'm too cynical, but working with Intel as such a small entity can be dangerous.
Blanket statement that could apply to any architecture. Intel is moving from 22nm to 14nm this year.First there's the possibility of missing out on all the great things arm could have in the future,
Switching from OMAP to Snapdragon to Bay Trail to etc... - it's all similar. All require redesigning the motherboard. Many of the features on the board post the SoC are similar no matter which is used.we may need to switch back to arm at some point;
Why would you assume they would be malevolent? Because they're huge? Intel is huge. It's like steering an aircraft carrier. They're not going to change course over this project. It takes years for them to change product plans. To 'screw us over' they would have to stop their 2 year mobile AND embedded roadmaps and buy every SoC from every reseller and screw the world. Which would be rather silly since they just released the most open mobile SoC in modern history.second if Intel wants to screw us over just right after Ed has spent all his capital on making a fully functional and finalised product, it can and will.
At that mythical point where super-agile Intel removes all of their mobile products from the market and reclaims all items in the reseller pipeline. Mmmm...K.We will have no place to back up to at that point because there's not as many alternatives in x86 as in arm.
Agreed - I like having devs interested in the project too. I'd like to make it easy for them with well documented hardware and open source drivers for everything including video. That would be awesome!It's also worth of mentioning that it is the developers in the user base made pandora different, not the end users. It's a sounder approach to try our best to keep the devs happy and give them meanings to stay.
Hold on - did you just state the the more bugs we have and the harder they are to work on is -better- for the project and end device? Whhhaaat???Leaving them with much to do, much to solve is better.
Niche as in elite as in new user hostile boards and device that can only be run if you read 300 pages of forums to figure out how to set it up?Staying with arm will at least keep the pyra unique if only as a niche product,
Hype train? No hype, just facts. Read up on the facts, you'll be amazed with the results.Outright fabrication: "Generic x86/windows smart device" The X86 crowd wants a Pandora style gamer's handheld on 64bit Debian on a z3770 SoC. Do you have any concept of how not-generic that really is?jumping the hype train may convert it into another generic x86/windows smart device.
And three statements earlier you wanted to make sure that it was complicated and hard to work on so that the devs had more to do and felt more loved. You want simple and stupid? Intel makes a NUC (New Unit Computing) box using a N2820 SoC which is in the same family as the z3770. Linux Kernel 3.14 installs and runs it out of the box with X and acceleration. http://www.phoronix.com/scan.php?page=article&item=intel_baytrail_nuc&num=1I would say if Ed has millions to spend then he can do what ever he could, but with only one shot at it, staying simple and stupid is always the best approach. (Engineering 101)
How's this - make a system that, for the most part, the core system simply works - then the devs can move on to fixing and improving on all of the 'other bits' that are sure to get added onto the system, porting over orphaned PND programs that don't already exist in the Debian repository and optimizing to the new hardware. Do this by picking hardware that is already in the Linux kernel (3.14 and above), is well documented (full fact sheets), etc...