Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Friday August 25 2017, @07:44AM   Printer-friendly
from the I-need-a-new-IoT...-and-make-it-Snappy! dept.

Submitted via IRC for TheMightyBuzzard

Snappy, a software deployment and management system designed by Canonical for the Ubuntu operating system, could be a shortcut to building trusted IoT applications.

The first rule of building a secure and feature-rich ecosystem is software management — push and pull software updates and software discovery through an app store mechanism from a trusted source.

In the go-to-market IoT race, though, that often doesn't happen. Many Internet of Things (IoT) product developers have ignored the traumatic early history of Microsoft Windows, Android and web platforms, and expoits of IoT devices — because software updates have not been designed in — are regularly reported.

Those earlier platforms have been hardened, updates have been automated, and the app discovery and installation have been made trustworthy. IoT developers need to follow their lead. 

Snappy, a software deployment and package management system designed and built by Canonical for the Ubuntu operating system, could be a shortcut to building a trusted IoT application.

The Ubuntu-Core required to integrate Snappy software management system uses 612MB, and snapd, the endpoint software management service needed to interact with Snappy, uses 15MB. The IoT device would need 627MB-plus memory for the IoT app called a snap. Because of memory and computational constraints, it is not a solution for ultra-low-power, small memory microcontroller devices but would work with 32-bit devices like the Raspberry Pi. Nevertheless, a review of Snappy is worth the time because it clearly explains a fairly complete approach to the problem of trusted software management and distribution.

Source: https://www.networkworld.com/article/3219725/internet-of-things/this-linux-tool-could-improve-the-security-of-iot-devices.html


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by Arik on Friday August 25 2017, @10:07PM

    by Arik (4543) on Friday August 25 2017, @10:07PM (#559131) Journal
    "Not every frigging device has 700 MB of free space, especially the IoT/embbedded stuff. FYI an arduino UNO rev 3 has 32 KB of flash memory."

    The thing is there's this CADT attitude that fully understands that many embedded devices today work in those limitations and doesn't care. Because they presume constantly increasing hardware specs, so sure that may be the rev3 but the 4 or 5 or 6 will "grow up" and be able to handle the bloat.

    Well first off, increases in hardware specs aren't so reliable as they used to be, a lot of the tech is nearing firm limits. But second, if you're making a single purpose device, it's *undesirable* to have more capability than needed. It's not just low value, it's negative value. I don't care if you can put a GB in the same space as 32kb for the same price, when you're making a garage door opener 32kb is better. Larger process makes it more reliable, it's more than enough memory to do the job, and there's no gain - only potential losses - in giving it more than it needs.

    But the manufacturer makes more money the other way. Less robust equipment that requires replacement more often. Plenty of RAM so you can hire a bunch of monkeys to code it in visual basic and still have room for your spyware and adware etc.

    In a healthy market the manufacturers wouldn't do this for long, even if they somehow did get in the habit, because customers wouldn't stand for it. But since computers are magic customers don't even understand that they're getting screwed.
    --
    If laughter is the best medicine, who are the best doctors?
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2