SoylentNews is people
SoylentNews
from the next-up-are-mcot-msofa-and-mrecliner dept.
Reported last week at the BBC, CNet and IEEE Spectrum is the news that ARM is launching a new OS targeting low power, low footprint devices.
The operating system, called mbed OS, is meant to resolve productivity problems that arise from fragmentation—where different devices in the so-called “Internet of things” (IoT) market run on a hodgepodge of different protocols. ARM is looking to consolidate those devices under a single software layer that's simple, secure, and free for all manufacturers to use.
(Although the IEEE article reports that "this is the first operating system ARM has ever developed", that slightly glosses over the history of RiscOS by Acorn, of which ARM was a subsidiary.)
The software comes as a free "mbed OS" and a licensable "Device server". Although parts of the OS will be open source:
ARM says it wants to retain control of other parts to ensure mbed remains unfragmented
More technical details at the mbed developer site. One oddity is the Online Toolchain, which provides the device IDE and version control online.
(Score: 2) by BasilBrush on Tuesday October 07 2014, @05:40PM
Suppose one won't ever use TCP, but will use IP. Then one might save some serious amount of memory by ripping TCP out. One might need to have some extra setting per packet buffer etc.
These are exactly the kind of things that will fragment the internet of things. Well done for demonstrating exactly why this OS is a good idea.
If you want to hack around with stuff that's NOT for commercial products that need to have widespread connectivity, there's nothing to stop you using another OS. That doesn't make it a bad idea to have a standard OS that will make the internet of things work more reliably. It's actually a very good design goal.
Hurrah! Quoting works now!
(Score: 3, Insightful) by kaszz on Tuesday October 07 2014, @05:49PM
Why keep TCP around in a box that will never use it? and where flash and RAM comes at a premium. Every byte counts. The main repository don't get modified. One branch, modify and deploy.
(Score: 2) by BasilBrush on Tuesday October 07 2014, @06:10PM
First of all, if you will never use TCP, you're not part of the internet of things. You're an incompatible oddity - and that's exactly what this OS is intended to discourage.
Secondly, if every byte were to count, you wouldn't be using a 32/64 bit chip like an ARM Cortex. So it's irrelevant. Moores law has made the few KB that a TCP layer needs an irrelevance for anything that's sophisticated enough to be networked.
Hurrah! Quoting works now!
(Score: 3, Interesting) by kaszz on Tuesday October 07 2014, @06:19PM
UDP is then never a part of Internet of Things? neither IGMP, multicast etc either?
How many bytes you can afford is also dependent on how much other stuff there is. And TCP is guaranteed to be way more than a 1 kByte in most circumstances.
(Score: 1) by lizardloop on Wednesday October 08 2014, @08:14AM
I think the point Basil was trying to make is that for an internet of things to work then the communication methods need to be standardised. Something that is probably best handled at the OS level by large vendors than by each individual device manufacturer. Ideally a device manufacturer would not be dictating whether or not they use TCP. They would just use whatever the standardised communication method was.
(Score: 2) by kaszz on Wednesday October 08 2014, @01:20PM
The problem isn't likely to be the OS. It's going to be what you fill those standard compliant UDP (or TCP) packets with. And the lack of security for any application. If security is implemented, it's usually tied to the vendor in way that is detrimental to the customer. Asfaik there's no standard for say IP aware light bulbs. And there will likely be as many protocols as there is vendors.
OS API is of course another area of incompatibility.
(Score: 2) by VLM on Tuesday October 07 2014, @05:57PM
How could thinks work more reliably if your app can't use TCP anyway?
That might be a bad example in a device specifically all networked up. How about ripping out network hardware drivers for hardware you'll never be able to physically attach to your device, or ripping out the entire sound system if you have no sound hardware on your device at all? Other than not being vulnerable to .ru or NSA hacking attempts on services you don't even have anymore, I'm not seeing a downside.
Does market fragmentation matter if you'll never install "stuff" on an appliance anyway? Fragmentation matters if you can't install angry birds on your new phone. I have no idea why I'd want to install angry birds on my waffle iron. Fried chicken and waffles, I guess.
If my dehumidifier fragmented, would I know or care?
(Score: 2) by BasilBrush on Tuesday October 07 2014, @06:22PM
How about ripping out network hardware drivers for hardware you'll never be able to physically attach to your device, or ripping out the entire sound system if you have no sound hardware on your device at all?
What makes you think you can't? It's "an integrated set of components". Just because you don't have all the source doesn't mean you can't choose the components you include.
Does market fragmentation matter if you'll never install "stuff" on an appliance anyway?
How are we going to have things working together if there's not compatibility? Whether your fridge is going to communicate with the electricity supplier, or your TV is going to communicate with your house lights. It needs compatibility at the network level, which we already have so long as some fruitcake doesn't rip out TCP. But it also needs higher level software components that know what these things can do and control them to do useful things. That may or may not be a user concept of "apps", but whatever it is, it's software that runs on an OS and operates at a higher level than network protocols. They are certainly enabled and more likely to be compatible if they are using the same APIS on the same OS. Especially when that OS is unfragmented.
Hurrah! Quoting works now!
(Score: 1) by lizardloop on Wednesday October 08 2014, @08:40AM
fruitcake doesn't rip out TCP
For some reason this made me giggle.
(Score: 2) by BasilBrush on Tuesday October 07 2014, @06:26PM
If my dehumidifier fragmented, would I know or care?
Don't confuse it with the question of whether networking is useful for a given category of device. If a device can be usefully networked, then it's an advantage if it's compatible with other networkable devices. Fragmentation is a pain in the arse.
If it's not work networking, then OS is irrelevant. Does you humidifier even contain a CPU? Mine doesn't.
Hurrah! Quoting works now!
(Score: 2) by VLM on Tuesday October 07 2014, @06:55PM
"Does you humidifier even contain a CPU? Mine doesn't."
Mine unfortunately does to run the touch screen. I bought the wrong model. If I had purchased the "dumb" one for about $5 less then I could switch the physical controls on, then plug the works into an appliance module and control it via my Misterhouse automation system. So not noisy running while I'm asleep but on every day while I'm at work and auto-on-off depending on my presence or lack there of in the basement (based on light switch) With some hysteresis so its not toggling on/off for no reason when I'm just getting laundry.
Thats the other extreme, where a dumb appliance is paradoxically easier to control than a smart appliance.
The Chinese value engineers are falling down on the job, this thing is like 10 years old and hasn't self destructed yet, they're leaving a lot of profit on the table. I'm sure new model ones only last 2 years now. Eventually I'll replace it with a really dumb dehumidifier and I'll automate it.