Slashdot Mirror
Intel Quietly Discontinues Galileo, Joule, and Edison Development Boards (intel.com)
Intel is discontinuing its Galileo, Joule, and Edison lineups of development boards. The chip-maker quietly made the announcement last week. From company's announcement: Intel Corporation will discontinue manufacturing and selling all skus of the Intel Galileo development board. Shipment of all Intel Galileo product skus ordered before the last order date will continue to be available from Intel until December 16, 2017. [...] Intel will discontinue manufacturing and selling all skus of the Intel Joule Compute Modules and Developer Kits (known as Intel 500 Series compute modules in People's Republic of China). Shipment of all Intel Joule products skus ordered before the last order date will continue to be available from Intel until December 16, 2017. Last time orders (LTO) for any Intel Joule products must be placed with Intel by September 16, 2017. [...] Intel will discontinue manufacturing and selling all skus of the Intel Edison compute modules and developer kits. Shipment of all Intel Edison product skus ordered before the last order date will continue to be available from Intel until December 16, 2017. Last time orders (LTO) for any Intel Edison products must be placed with Intel by September 16, 2017. All orders placed with Intel for Intel Edison products are non-cancelable and non-returnable after September 16, 2017. The company hasn't shared any explanation for why it is discontinuing the aforementioned development boards. Intel launched the Galileo, an Arduino-compatible mini computer in 2013, the Edison in 2014, and the Joule last year. The company touted the Joule as its "most powerful dev kit." You can find the announcement posts here.
I'm not surprised Intel is doing this. When your competition for IoT devices includes widely available Arduino, Raspberry Pi and other simple, cheap boards with legions of followers? Embedded stuff is either going to COTS (Common Off The Shelf) stuff or very highly customized. At least that's my thought.
Never have a philosophy which supports a lack of courage
Exactly. Why buy into an ecosystem that's not as flexible as the others. Did they offer superior documentation and support? Superior integration? Anything at all aside the brand?
Guessing the bosses at the top want to retrench and focus on their server & consumer spaces now that AMD has shaken up the market once more. Despite this being a tiny space, I doubt it ever made enough money to justify the ongoing costs needed to crowd out all of the established open hardware.
I don't know anything; please explain the following:
Nobody here wants to teach you basic electronics. Do the research yourself, lazy fucker.
It means that the GPIO is not
A GPIO is a general-purpose input/output
An input/output pin is
I give up. Go read stuff on MSNBC, reddit or somewhere else.
#DeleteFacebook
What's so pathetic about this is that they basically pulled a Microsoft-and-mobile on this.
Arduino, BBB, and RPi had already been out for years before Intel finally figured out that there was a market there.
Then, when they finally got off their butts they came to the party with a stupidly overpriced offering that didn't fit with the existing ecosystem.
Why did they even try doing their own thing at all instead of helping to improve what already existed? For example, why not work with ODROID to put Intel chips on their boards instead of ARM?
This whole thing was stupid and ham-fisted on Intel's part-- whoever the exec was that made the decision should get a stern talking-to.
This also matches up with Intel's flailing in response to AMD's recent surge (sad as it was that AMD was on the ropes for so long).
To add onto your post,
When I was in college, I backed/bought a 3rd party board. It was faster than Arduino but pin compatible. It was before there were so many options but the experience is still applicable.
I bought it, and ran into problems. The hardware was fine but the SOFTWARE chain had problems crashing the IDE, and flashing/detecting the serial port. It was a pain in the ass. "Go online and search for a fix" doesn't actually work when: There's like 10 people at the company and
Another slap to the face? I realized I had bought a "Beta" board. They said it could have problems but it was tested and sound. The problem? They then produced the "official" board which wasn't pin or software compatible with the Beta board.
So I spent $60-80... on a paperweight that can't be programmed.
Additionally, there are zero 3rd party tutorials, almost zero forums with knowledge of the device. It's almost impossible to crowdsource a problem with it.
Another problem? Just like Intel here, what happens if the product is discontinued or no longer supported by the company?
I've learned the hard way that you're not buying a product, you're buying a PLATFORM. And the platform (documentation, official and third-party support, hardware, and more?) needs to be heavily entwined in your cost/benefit calculations. It can't just be "speed vs cost."
As I've looked for better Arduino and Raspberry Pi's, I've consistently applied that logic and found zero viable alternatives. Even if they could compete on cost, they can't compete on TIME investment. There are thousands of arduino/pi tutorials. Good official documentation. Thousands of active programmers to assist you and over a decade of toolchain support.
I've been learning the D language over the last year or two. I love it (except the garbage collector which adds an additional entire dimension to crash solving). Otherwise, it's pretty amazing (so much so the C++ committee adds features that D had for over a decade). They have one great forum and StackOverflow probably can solve it. But that's kind of it. There aren't dozens of _maintained_ D XML parsing libraries. Dozens of JSON libraries. Dozens of game programming libraries. Dozens of X/Y/Z libraries. In C and C++ you have your pick of the litter. Any possible question, no matter how niche, has a C/C++ library. Library for the reverse engineered Kinect2 sensor? Yep. But while D can interface cleanly with C, it doesn't support C++. And that's a huge flaw because it cuts you off from basically "Almost every library ever written" in the last three decades. Programming in D is a delight, but you HAVE to re-invent the wheel for things that come for free in C/C++. So I've been very hesitant to switch over completely to D. What happens if the community dies out? Do I really want to write a hobby game in a dead language? (There is a fork of LLVM based LDC, Calypso, which integrates Clang with LDC for C++ support. And it's a highly watched project. But it's even more niche. Do I hedge my game on an almost-niche language, with a niche fork of a compiler that is 300 commits behind the official LDC branch? What if I run into a bug that is solved in the new branch but not the fork? I'm relying on a lot of guys charity work in my build chain.)
So if I can distill all my points down to one: "For production, buy what's popular--not what's clever."