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 kaszz on Tuesday October 07 2014, @04:29PM
Releasing an operating system for embedded use which is an environment where changes to the OS is hard to avoid in order to make it work. And on top of that giving away corporate and other secrets to their "online toolchain". It's a bad joke!
(Score: 4, Insightful) by kaszz on Tuesday October 07 2014, @04:32PM
Embedded environment means you often have to apply changes. And distribute them onto your devices. Any non really permissive license will get in the way.
And that online toolchain is likely to be abused by 3-letter organizations, unless it won't send special commands to make your hardware act in ways that is against your wishes.
Stop this trend of goods pw0ned by design.
(Score: 3, Informative) by BasilBrush on Tuesday October 07 2014, @05:27PM
Any non really permissive license will get in the way.
QNX is an example of a non-open source embedded OS that's been successfully and widely used for embedded systems for 30 years.
And that online toolchain is likely to be abused by 3-letter organizations, unless it won't send special commands to make your hardware act in ways that is against your wishes.
Heartbleed was used by the NSA to spy on people for years. Open source is no defence against spys. Indeed the essentially anonymous origin of the source means that it's easy for spys from any country to insert their own vulnerabilities. Far easier than with a credible single origin such as ARM.
Hurrah! Quoting works now!
(Score: 2) by kaszz on Tuesday October 07 2014, @05:41PM
QNX will fit the bill for some. For others you won't hear about their solution.
Heartbleed is something you can fix and make clean house with because you have the source and the right to meddle with it. And don't have to be wired up to a specific company to make use of it. Corporations can no longer be credible. They will do whatever the magic letter agents want.
(Score: 2) by BasilBrush on Tuesday October 07 2014, @06:00PM
QNX will fit the bill for some.
And mbed will fit the bill for some. Just showing that this kneejerk reaction that because it's closed source it is hard to use and a joke is pure nonsense.
Heartbleed is something you can fix and make clean house with because you have the source and the right to meddle with it.
No-one fixed it for 14 years, because no-one who found it made it known. And for some amount of that time the NSA had found it and was actively making use of it. So open source proved more of an advantage for the NSA than for it's end users. It's open source that's lost it's credibility.
Hurrah! Quoting works now!
(Score: 2) by kaszz on Tuesday October 07 2014, @06:15PM
mbed is not a fully free solution so it brings only a tainted tool to the table.
And proprietary software lost all credibility a long time ago.
(Score: 2) by q.kontinuum on Tuesday October 07 2014, @06:33PM
Open source is no guarantee for safety, but it increases the chances. First of all, the source code has nowadays usually better quality [coverity.com], because people use their contributions to brush up their CVs and second, the maintainer is not necessarily in close contact with all developers, so the code needs to be understandable.
Also, open source does not allow for crude implementations of security by obscurity, and bug-fixes are not dependant on some manager deciding about profitability, weighing in the chance of selling an upgrade instead. There is no reason closed source should be safer, even though open source does not guarantee safety.
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 2) by BasilBrush on Tuesday October 07 2014, @07:16PM
Regarding the Coverity report.
1) It says that according to their scans, open source is better quality in 2013 "for the first time". Yet the claim of open source being better quality goes back at least 17 years to The Cathedral and the Bazaar. So is this an admission that the claim was untrue for most of that time?
2) I'm not convinced it's comparing like with like. Systems software is by it's nature more hardened than application software. And software made by a software company selling as a product will be higher than a enterprises bespoke app. Anonymously donated enterprise software is not the same as closed source software as a whole. Valuable closed source software stays closed. None of the closed source software I've worked on would ever find its way into a Coverity report.
Also, open source does not allow for crude implementations of security by obscurity
What do you think port knocking is?
Hurrah! Quoting works now!
(Score: 2) by q.kontinuum on Wednesday October 08 2014, @04:28AM
The generalisation was wrong. But this link [lwn.net] shows that the linux kernel has a long history of good code quality compared to most enterprise software.
I agree. For open source software, the scan is free of charge, so any minor project can sign up without any barrier for proficiency. For closed source projects it is an investment, which will only be done by already quality-conscious development teams with willingness to invest not only time but also money in code quality. That creates a bias for enterprise software. Under these circumstances it is even more surprising that open source quality is higher.
A simple form of password protection. (I assume the ports which need to be knocked are configurable, not hardcoded in software.)
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 2) by BasilBrush on Tuesday October 07 2014, @05:14PM
Releasing an operating system for embedded use which is an environment where changes to the OS is hard to avoid in order to make it work.
If you need to change the OS, rather than a device driver or userland program, you're doing it wrong. Saving the internet of things from the fragmentation of people needlessly fucking about is a design goal.
Hurrah! Quoting works now!
(Score: 3, Informative) by kaszz on Tuesday October 07 2014, @05:19PM
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. Point is that the OS designer can't know how it will be used. And there isn't space to put in code for all usage scenarios like it's done on a desktop or server environment.
(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.
(Score: 2) by VLM on Tuesday October 07 2014, @05:42PM
So if, like me, you want to see the internet of things fail miserably and go away, all I need to do is
needlessly fucking about
The good news is I'm pretty good at that, but the bad news is I don't think its quite that simple.
Then again it'll probably fail all on its own without anyones help.
(What I don't like about IoT is the full formal name will be "Internet of Things controlled by the NSA and russian botnets, not you, although you paid for it all and the only way to un-pown your basement furnace will be to buy another")
Anecdote time: My mother in law has the most secure smart TV I've ever heard of... she doesn't have internet. It was on sale and cheaper than the equal size dumb TV, weird as that sounds. Model year clearance or maybe she got a 720 instead of a 1080, her sight isn't so great so it doesn't matter anyway, donno.