Intel to cut IoT jobs
electronicsweekly.com
electronicsweekly.com
For example, there are so many parts on the Texas Instruments web site for which you can not get any support, unless you are a heavy volume customer. They even turned some of their product forums to "read-only". You can't even post a public question anymore.
Similarly, Xilinx had an official support channel (Webcase). A few years ago, they made to decision to only have that support channel open to their Tier 1 (or whatever they call them) customers. We can no longer ask for direct support from Xilinx with the money we spend on their chips (~100K USD worth of FPGAs) every year.
... and don't get me started on Qualcomm.
This isn't a surprise to anyone who's encountered any Intel IoT product. I think for most of us, the biggest question was why it took Intel so long to pull the plug.
Intel released products for IoT, then didn't update them forever (look at how many times they announced successors [0] [1] to the Quark) and they wonder why no one was interested to build products with their solutions.
As an aside, this article is terribly written (grammatical errors everywhere, spelling mistakes like "msrket").
[0] http://www.cpu-world.com/news_2014/2014070801__Dublin_Bay_So...
[1] http://wccftech.com/intel-quark-liffy-island-seal-beach-proc...
[1] Disclaimer: When I looked at it when they were released. Perhaps it was addressed later.
$721m divided by 97 would be applicable if the entire IoT group consisted of those 97 people but it's not. I can see that the article makes it confusing and some might interpret it as if Intel is laying off all the IoT employees. (I don't know how many total Intel IoT employees there are since Intel doesn't seem to not have publicized that headcount.)
My guess is that since Intel recently discontinued x86-based IoT boards (Joule, Galileo, and Edison), many of the layoffs are directly connected to that.
Intel is still in the IoT game but pursuing other strategies to compete with the low-power-more-efficient ARM-based IoT market.
it is very likely that they were actually making losses
I too suspect this was not a profit-in-the-now division. They were probably playing a long-term game. I think they ceded the game to someone else .. but who?
~550/580
Everyone everwhere in business loves growth. If there's a new market that never existed before, or if you can take away a competitor's share, you win.
It makes sense for Intel and its competitors to invest in growth markets like IoT. But if its offerings don't meet the need or the R&D expense doesn't pay off after a few years, it makes sense to retreat.
Intel is going to have quite a few more innovator's dilemmas in the next few years, including in the notebook market, which I imagine Intel will eventually deem it "unprofitable" because of AMD and Qualcomm's aggressive offerings, and it will get out and run to its server profits.
Intel seems to know they need to break into new business. But doing that with the mindset and within the constraints of a quasi monopolist is very, very hard. Building something new requires not just resources but calendar time, commitment and freedom not just on the technical but also on the business model side. Focusing on your core strength is an excellent mantra until one is in a corner and by then it is hard to think different.
I don't think they actually care (yet) because a few billions is peanuts to them as long as they have their high margin business but the wolves are at the door.
AMD is actually much better positioned because they have gone through a very painful restructuring and reorientation toward a business model that works with low-margins and they now seem to be coming out the other side.
Intel will eventually have to go through the same restructuring and it will be even more painful for them because they have a lot further to fall.
Gpu technology from Nvidia is continuing to unlock new capabilities that make upgrading a CPU less important and as more code becomes gpu dependent it'll matter less what CPU architecture you are running.
That opens the door for arm to enter the server market.
That is doom for Intel.
I believe that they are acutely aware of that, but at the moment they chose "to not to slaughter a hen laying golden eggs"
The difference is that this is a new product category for them, rather than a new microarch in an existing category.
And from recent appearance, I'd say they're not great at building new ecosystems (IA-64, mobile, now IoT).
Sure someone still needs to write those AOT/JIT compiler backends and virtualization layers, but it has become a thin layer in the overall stack.
Probably only when porting binaries, or Assembly/intrisics heavy code.
Having a mini-ITX for everything, including even nas storage (I hate the people calling this cloud storage), is so much better it's ridiculous.
Other than smart lightbulbs, I mean, which are a tiny, tiny market. Why are companies like Cisco interested ? Why was intel interested ?
Personally, the consumer side is the noisy part, but not the part that I see changing the world most drastically. Making the world around you and businesses everywhere more automated, better controlled & more efficient is going to make more of a meaningful difference to the world that adding connectivity to your toothbrush.
The Pi chip was originally designed for set-top-box usage. Much of the die is video decoder, I believe. So if you have the right drivers and maybe an MPEG2 license it should be fast. https://www.raspberrypi.org/blog/new-video-features/
Your average set-top-box (cable or whatever) doesn't have an x86 and it runs fine. But accelerated video play requires proprietary software
Not sure how it works on Android, but I guess it's more or less integrated there (so you can have accelerated video play easily and "in the system")
Most vulnerabilities do not derive from it
Just a few years ago smart TVs, one example of such platforms, had overscan, some without the ability to disable it. (Make the screen look bigger by only showing the middle part of the video)
UHD blows out any dual-core CPU (maybe quad can do it?) so dedicated hardware is an absolute necessity for that.
Even if you could decode video in software the power efficiency is so much worse than using dedicated hardware that it is really impractical.
I am using the video decoder on an Nvidia GTX-1060 and I am paying a huge price for a lot of wasted hardware in order to get access to that. And I am forced to use Windows anyway since I can't get Kodi to sync the refresh rate properly on Linux and a couple hours of wasted time trying to fix that is the limit of my patience.
IMO fixed hardware based on ARM (which costs about $100 vs $1000+) is obviously the better solution for price/performance on video.
What I am paying for is the aesthetic (HDPLEX HD5 case) and the enjoyment of having something I built myself, not technical superiority.
It might actually be easier for you to get a dual core which can decode everything you want. Any high-clocked desktop Core i3 should easily handle any reasonable bitrate 4k video in any codec on the market. If it doesn't then there's something very wrong with your video decoder software.
More to the point, why would I want to burn 100 watts decoding this in software when I can do it in single digits with fixed function hardware?
[edit]
You may be talking about videos that can use Intel's own fixed function video decoding hardware, which will work just fine on an i3. I am talking about 10bit h265 which Intel Skylake didn't support when I was building my system. Kaby Lake supports it now so if you are building a new system Kaby Lake would be the way to go.
This would mean an open market with a fierce concurrency (and low margins).
I hope that this is the future, but Intel like many chip makers are fighting against it by blocking documentation of their products (using NDA and/or huge prices).
Some versions of those things may go mainstream, but only after they get to the point where people don't have to do the technical and creative work (e.g., click a button and your 3D printer makes the new iPhone case you want, so you don't have to wait for it to be delivered).
Maybe 1%-2%.
Most "Internet of Things" devices just don't do very much. They lack any actuators.
There are lots of things that can be done to make heating, ventilation, and air conditioning more efficient and comfortable. But the good stuff requires installation. Mechanisms to open and close windows. Dampers. Sensors for humidity, CO2, CO, temperature, rain, and fire. Wired connections to everything. (Battery replacement is unacceptable in commercial environments.) All this is available from major HVAC vendors. Usually for too much money. (Window openers seem to start at $500 per window, so nobody buys them.)
A few years ago I went to an IoT meetup in SF, in the Dogpatch area. This was in an old industrial building. Skylights overhead had openable windows on manual chain falls. Outside windows overlooking the bay were openable. There were overhead fans and a standard HVAC system. None of this was powered and controlled. So the place overheated and became uncomfortable with too many people inside.
In a space like that, as more people come in and the CO2 level goes up, the overhead windows and side windows should open and the overhead fans should go into reverse to bring down the CO2 level. Then the side windows should be adjusted to maintain temperature. As evening comes and the outside temperature drops, the side windows should close more. At some point, heat may be required. As people start to leave, the CO2 level will drop, the overhead windows start to close and the fan speed drops. When everyone leaves, and the motion detectors see no movement, everything closes up and the temperature is allowed to drop to 60F or so for the night.
Some hotels have systems like that in function rooms. Any space with a widely variable people load, such as a classroom or conference room, should be equipped with CO2, humidity, and temperature sensors connected to actuators which can do something about it.
"Get into IoT with Intel" - https://register.gotowebinar.com/register/108829149494036582...
Have they not learned from the Xscale fiasco that dropping a soon-to-be hugely important market is not the best strategic move?
And it's not like both predictions are/were any difficult to make.
They have the technical chops to do it right, their mainstream CPUs are ample proof of that, and this sector will get a lot bigger. Their top management either lacks the balls/vision to drive the idea to success, or is acutely aware that they would never, ever be profitable in a market where the end product is under $40 (sometimes under $5).
I don't know which alternative is sadder.
Many times companies will try to get into new markets or channels as a hedge, just in case their cash cow goes tits up. I give them credit for seeing that it was right to bail.
Closing a $700m unit and laying people off is a pretty big admission of a mistake - they just see there's no viable course correction. Giving up is sometimes the best option.
Because their name stands for INTegrated ELectronics and they just failed at it.
> Closing a $700m unit and laying people off is a pretty big admission of a mistake - they just see there's no viable course correction. Giving up is sometimes the best option.
Agreed, not disputing that, just trying to analyze the reasons behind the failure.
How many times have we seen this: an exec runs with an idea, but it doesn't pan out fast enough. Other execs then have a stick they can use to embiggen themselves at the expense of their colleague. The end result is that the idea itself is now tainted and no one will touch it.
Intel has tried multiple times for the embedded market, so far not that great.
I'm now watching the yocto project for what Intel is the main force behind, it is a bad idea(over engineered to say the least) with a few good people running it.
Better is a relative term and may be different between your use case and mine.
I found the LWN article to be very useful: https://lwn.net/Articles/682540/
The full "wisdom" of the internet: https://www.google.com/search?q=buildroot+vs+yocto
It seems like people tend to say Yocto is a bad idea, but that's just their gut feelings (and mine as well) with no substance in it except yocto's complexity.
-- Yocto is complex without giving you anything much back in exchange. Pathnames are longer, directory names are counter-intuitive and do not emphasize the main task of a developer/integrator: work with the source code. Probably more bearable if one only checks out the whole tree, starts the build and go on lunch... but then comes the next item:
-- Yocto is more resource demanding (again, personal, compared to some systems I used before): more memory, more CPU cores for the builder VM, more storage -- for the same build we did before.
-- Yocto fails its promise to decouple the delivery from the FOSS sofgtware: every once in a while, a public repo goes offline, and angry customers call back. One still has to deal with the public repos you pull into the build, no matter what yocto advocates told you -- might as well copy it into the tree already.
Buildroot suffers from some of the above as well (my BR experience dates from ~5 years ago, I am not a fan of it).
On the flip side, Yocto is probably cleaner than buildroot for cross-building. It could also be easier in including new components into the build, haven't tried that.
Over time, I worked out some personal indicators I use to gauge the building/versioning harness:
-- how many macros and environment variables the makefiles / scripts / receipes contain and refer to. The lesser is the better;
-- how easily I can navigate in the source code: how long pathnames, how much typing to go to another source file; how many additional pulls/checkouts/fetches/unpacks are required. etc.
-- how "cross-clean" building it is: all required host-, target- and cross- tools need to live inside the same tree, and be built during the main build if necessary. Having a mandatory separate VM is usually an o_O sign.
I've created a couple of simple buildroot packages and it was nearly trivial. The buildroot preference is touse cmake for the package build support - I went with that and was very happy with the level of effort required (low!).
http://docs.automotivelinux.org/docs/getting_started/en/dev/...
If they want to tend to these markets, they are going to have to give up on being the single source.
Seems that Intel, sales $721 million after several years of work, has a similar metric for new business opportunities.
Also despite of the hype IoT was not such a big thing (despite for the hobbyist market, where people(me included) get quite excited by building a temperature logger)
We had a comparable theme on the Curie/Edison/Quark post a few weeks back. They just don't seem to get it.
AMP pages load super fast for me on mobile so not sure how you can say that if you're just basing that on not understanding the design choices behind AMP.
Would have been nice if the author had investigated why Google is recommending so many JavaScript libraries that seem so large instead of just assuming it was a very bad idea. For one, AMP will be loading the JavaScript in a non-blocking manner so the page will appear to load fast and if you've visited an AMP page before the JavaScript will be cached (unless there's so many different versions...?).