Link alla notizia: http://www.hwupgrade.it/news/sistemi-operativi/arm-annuncia-mbed-os-un-nuovo-sistema-operativo-per-l-internet-delle-cose_54311.html

mbed OS è un sistema operativo per i microcontroller installati nei dispositivi connessi ad internet

Click sul link per visualizzare la notizia.

mi sarebbe piaciuto provarlo (il mio netduino 2 plus supera abbondantemente i requisiti minimi di ram e flash), ma se non ho capito male non sarà liberamente disponibile

a questo punto però non vedo perché usarlo visto che ci sono tantissime alternative, anche open source (anche il .net micro del netduino sopra citato)

Se viene fornito insieme alle licenze ARM, secondo be ha discrete possibilità di diventare uno standard nel settore. ARM ha fatto bene a pensare ad un sistema che fosse pronto insieme all'hardware che deve pilotare.
Bisogna poi vedere se e quali saranno i vantaggi e gli svantaggi rispetto ai ciò che già il mercato offre: in questo settore un minor uso di risorse per esempio potrebbe rivelarsi determinante.

Sarà un sistema aperto e libero oppure no?

Sarà un sistema aperto e libero oppure no?

Secondo quanto scritto nella notizia, no

Sarà un sistema aperto e libero oppure no?Secondo quanto scritto nella notizia, no
allora bocciato. Gli ultimi eventi dovrebbero farci riflettere sul fatto che la vera sicurezza non puo' prescindere dalla possibilità di visionare il codice sorgente, piuttosto e anzichenò.

Non è detto che non sia open source.
Magari rilasceranno i sorgenti ai proprietari di licenza, o magari li renderanno pubblici ma il sistema sarà utilizzabile solo da chi acquista la licenza.
Se però sarà vincolato alla licenza, non sarà libero. A meno che non sia una scelta temporanea per il lancio e poi rilasciano tutto.

java e' la risposta. tanto spesso non serve un so, e quindi java e' perfetto.
del resto e' stato progettato proprio per questo.

java e' la risposta. tanto spesso non serve un so, e quindi java e' perfetto.
del resto e' stato progettato proprio per questo.

il mondo IoT (e in generale quello embedded) è caratterizzato da dispositivi poco potenti e in cui le risorse computazionali e di memoria sono sempre risicate (e si fa i tirchi pure con quelle)... java invece è avido di risorse, soprattutto di ram

java e' la risposta. tanto spesso non serve un so, e quindi java e' perfetto.
del resto e' stato progettato proprio per questo.

Embedded spesso è sinonimo di real-time, quindi a meno di versioni particolari, la risposta di cui parli sarebbe decisamente sbagliata.

allora bocciato. Gli ultimi eventi dovrebbero farci riflettere sul fatto che la vera sicurezza non puo' prescindere dalla possibilità di visionare il codice sorgente, piuttosto e anzichenò.

Beh oddio, Heartbleed non dimostra proprio questo eh... il fatto che il sorgente sia aperto non implica la sicurezza matematica del software, ma semplicemente che io o te possiamo guardarlo, se vogliamo.

allora bocciato. Gli ultimi eventi dovrebbero farci riflettere sul fatto che la vera sicurezza non puo' prescindere dalla possibilità di visionare il codice sorgente, piuttosto e anzichenò.

Se con "ultimi eventi" ti riferisci a Heartbleed e CVE-2014-6277 (peraltro vulnerabilità ampiamente gonfiate a dismisura dai media generalisti, visto che l'intervallo di minaccia di entrambe era molto ma molto stretto) ti faccio solo notare che erano (sono) due vulnerabilità di due software FOSS (uno era un bug di OpenSSL, l'altro di Bash). Sei caduto in un diffuso luogo comune, il software bug-free non esiste, né closed-source né, evidentemente, open.
La testa è il solo strumento in grado di proteggere gli utenti, un idiota su Linux è solo un idiota con un buon sistema operativo. Vice versa, un utente intelligente, anche con un OS di mxxxa, rimane abbastanza sgamato da non farsi fregare

Embedded spesso è sinonimo di real-time, quindi a meno di versioni particolari, la risposta di cui parli sarebbe decisamente sbagliata.

non e' cosi'. l'internet of things e' rivolto al 90% a elettrodomestici, tv, lettori blueray e roba del genere, dove non serve il real time. i miei vecchi decoder dtt sono java based, per dirne una, e un decoder dtt che registra che ho comprato da pochi mesi, e' java.
controlla bene, moltissimi dispositivi sono java based.

forse confondi "embedded" con "industriale", e in quel caso java non va bene, ma e' una frazione di tutto.

il mondo IoT (e in generale quello embedded) è caratterizzato da dispositivi poco potenti e in cui le risorse computazionali e di memoria sono sempre risicate (e si fa i tirchi pure con quelle)... java invece è avido di risorse, soprattutto di ram

java non e' cosi' avido come si crede, ne' lento.
ho visto decine di benchmark (sviluppando in c++ e java mi sono voluto informare), e la differenza e' minima.

Embedded spesso è sinonimo di real-time, quindi a meno di versioni particolari, la risposta di cui parli sarebbe decisamente sbagliata.

mbed OS è event driven, non real-time.

Se si ha bisogno di prestazioni realtime serve ben altro.

Ma d'altra parte in un sacco di applicazioni IoT non servono prestazioni realtime ma connettività (supporto di stack dei comunicazione, protocolli ed interfacce di vario tipo).

real-time non c'entra nulla con le prestazioni. è solo questione di vincoli da rispettare sulla schedulabilità dei processi.

Non confondere le prestazioni in generale con la sola potenza di calcolo. ;)

veramente non li sto confondendo, o forse non ho capito il senso del tuo commento originale, cosa intendi con prestazioni. ho visto microcontrollori ad otto bit in ambienti real time...

Se è per questo ce ne sono anche a 4bit se i task/thread critici sono sufficientemente leggeri o se i vincoli tipo WCET sono sufficientemente ampi.

I vincoli di un applicazione specifica non sono noti a priori ad un S.O. realtime "generico", per questo di solito si danno specifiche di riferimento tipo WCET per la gestione degli interrupt (da cui ricavare la capacità di calcolo "utilizzabile" con interrupt che arrivano con una certa frequenza), massima risoluzione (e precisione) temporale dei timer, overhead legato alla gestione di funzionalità specifiche ecc.
in modo da avere un idea di quale hardware utilizzare abbinato al S.O. prescelto.
Ed in tal senso più che di vincoli è il caso di parlare di prestazioni
(nel senso di prestazioni dell'accoppiata hardware+software realtime "di base" che devono essere tali poter rientrare nei vincoli associati invece all'applicazione/i specifica/che).