Nei piani futuri di Research In Motion c'è QNX

Nei piani futuri di Research In Motion c'è QNX

Research In Motion potrebbe in futuro abbandonare lo sviluppo di BlackBerryOS in favore di QNX

di pubblicata il , alle 09:30 nel canale Sistemi Operativi
 

Sembra che Research In Motion abbia in mente grandi progetti per QNX, il sistema operativo acquisito lo scorso maggio da Harman International. Oltre ad essere stato adottato come OS per il nuovo tablet PlayBook, pare infatti che in futuro QNX andrà a rimpiazzare BlackBerryOS.

Secondo quanto riportato dal sito web UnwiredView nel corso della presentazione di PlayBook uno dei vice presidenti di RIM ha confermato che l'azienda canadese intende servirsi in futuro del nuovo sistema operativo anche per i propri smartphone.

Nonostante RIM si sia innamorata della stabilità, delle capacità multimediali e del ridotto consumo energetico di QNX, la transizione da BlackBerryOS a QNX avverrà in modo lento e graduale.

A riprova del fatto che l'attesa sarà lunga, lo stesso vice presidente di RIM ha inoltre dichiarato che BlackBerryOS 7 sarà uno step fondamentale per il passaggio a QNX e considerando che BlackBerryOS 6 è stato rilasciato da poco, appare chiaro che ci vorranno ancora un paio di anni, nella migliore delle ipotesi.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione

15 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Opteranium30 Settembre 2010, 10:32 #1
ma qnx non era il s.o. che gira sulle centrali nucleari, lo shuttle e robot chirurgi?

ora anche i tablet?
pabloski30 Settembre 2010, 10:39 #2
la cosa divertente è che c'è gente ( non qui su hwupgrade per fortuna ) che afferma candidamente e con convinzione che sistemi come qnx non sono general purpose

evidentemente questa gente dovrebbe ritornare a scuola

comunque sia era logico che sarebbe finita così...qnx è un sistema operativo molto molto più avanti rispetto alla massa....nel mondo open ci vorrebbe una cosa del genere, speriamo che haiku smuova un pò le acque


Fulvi030 Settembre 2010, 10:52 #3
che amarcord QNX

impossibile dimenticare la demo su floppy... un S.O. con interfaccia grafica in un dischetto. C'era di che far stupire gli amici
an-cic30 Settembre 2010, 10:57 #4
Originariamente inviato da: Fulvi0
che amarcord QNX

impossibile dimenticare la demo su floppy... un S.O. con interfaccia grafica in un dischetto. C'era di che far stupire gli amici


di quanto tempo fà parli?

se andiamo molto indietro negli anni ce n'erano anche altri con interfaccia grafica che si caricava da dischetto!!!

ammetto che fino alla presentazione del playbook non avevo mai sentito parlare di qnx, ma stò dando un occhiata in giro e sembra molto interessante.
checo30 Settembre 2010, 11:05 #5
Originariamente inviato da: Opteranium
ma qnx non era il s.o. che gira sulle centrali nucleari, lo shuttle e robot chirurgi?

ora anche i tablet?

gira dove gira ci fossero app adatte all'uso domestico sarebbe pure general
eeetc30 Settembre 2010, 11:11 #6
Originariamente inviato da: Fulvi0
impossibile dimenticare la demo su floppy... un S.O. con interfaccia grafica in un dischetto. C'era di che far stupire gli amici

Come non quotarti!
JackZR30 Settembre 2010, 12:07 #7
Spero fondano i due progetti invece di scartare completamente il vecchio.
s0nnyd3marco30 Settembre 2010, 12:28 #8
Originariamente inviato da: pabloski
la cosa divertente è che c'è gente ( non qui su hwupgrade per fortuna ) che afferma candidamente e con convinzione che sistemi come qnx non sono general purpose

evidentemente questa gente dovrebbe ritornare a scuola

comunque sia era logico che sarebbe finita così...qnx è un sistema operativo molto molto più avanti rispetto alla massa....nel mondo open ci vorrebbe una cosa del genere, speriamo che haiku smuova un pò le acque


Perdonami, ma dire che qnx sia un sistema general purpose non e' corretto. Qnx e' un os realtime nato per sistemi embeded o dedicati all'automazione industriale. Mi spieghi a che servono le estensioni realtime ad un pc domestico?
Haiku non e' un os realtime, ma come il defunto beos, puntava molto alla multimedialita'. E sinceramente non credo che al team di sviluppo di haiku possa fregare qualcosa di entrare in quel mondo.
Se cerchi strumenti opensource per il realtime ce ne sono parecchi: uno di questi e' rtai.

Poi mi spieghi cosa intendi quando dici che qnx e' piu' avanti rispetto alla massa?
niko71730 Settembre 2010, 12:49 #9
Originariamente inviato da: s0nnyd3marco
Perdonami, ma dire che qnx sia un sistema general purpose non e' corretto. Qnx e' un os realtime nato per sistemi embeded o dedicati all'automazione industriale. Mi spieghi a che servono le estensioni realtime ad un pc domestico?
Haiku non e' un os realtime, ma come il defunto beos, puntava molto alla multimedialita'. E sinceramente non credo che al team di sviluppo di haiku possa fregare qualcosa di entrare in quel mondo.
Se cerchi strumenti opensource per il realtime ce ne sono parecchi: uno di questi e' rtai.

Poi mi spieghi cosa intendi quando dici che qnx e' piu' avanti rispetto alla massa?


Io una volta ho installato QNX sul mio pc, e devo dire che volevano "convertirlo" per uso domestico.... aveva supporto mp3, browser e tutte cose che sono richieste da un pc desktop. Purtroppo però alla fine ha fatto una brutta fine (io stesso l'ho subito disinstallato perchè non mi piaceva e creava solo problemi )
jappilas30 Settembre 2010, 13:09 #10
Originariamente inviato da: pabloski
la cosa divertente è che c'è gente ( non qui su hwupgrade per fortuna ) che afferma candidamente e con convinzione che sistemi come qnx non sono general purpose

il fatto è che ... non è del tutto inesatto, quantomeno sotto certi aspetti

quello che come si diceva all' inizio, rende QNX (ed altri sistemi della sua classe, tipo vxworks) adatto all' impiego nelle centrali nucleari, ma anche su robot chirurgici, elettromedicali, apparati di controllo ecc ecc, è il fatto di essere un OS realtime ovvero di supportare lo sviluppo e l' esecuzione di processi realtime - la cui caratteristica base come ogni programmatore sa, è di essere sottoposti a stringenti vincoli temporali (ad esempio sul tempo da cui un' operazione dev' essere eseguita ed entro cui dev' essere completata - e superato il quale si può parlare di fallimento)
ora, per garantire il rispetto di tali vincoli il sistema operativo dev' essere il più deterministico possibile (le latenze di system call e interrupt devono essere note, o quantomeno superiormente limitate con certezza, quantomeno per quel sistema su quell' hw), e deve mettere a disposizione delle facilities (come algoritmi di scheduling e meccanismi di sincronizzazione ad hoc) e un comportamento idonei all' esecuzione real time, su cui i progettisti di applicazioni ( il sistema di controllo della centrale dal punto di vista di neutrino - il microkernel di QNX - è nè più nè meno che un' applicazione) possano contare
ma la cosa interessante è che poi il sistema composto da applicazione realtime e kernel realtime, è tipicamente sviluppato staticamente, a partire da quest' ultimo, dalla conoscenza degli upper bound sulle latenze, e dei requisiti dell' applicazione (noti a priori, spesso e volentieri corrispondenti a variabili fisiche - tempo di apertura di una valvola, di spostamento di un attuatore, di acquisizione di un segnale a una certa frequenza eccetera) facendo attenzione, ad esempio, a che la somma delle risorse (cicli cpu, quindi timeslice) richieste da tutti i processi presenti in condizioni nominali, non superi quelle totali a disposizione (sull' hw target, ovvero su una specifica cpu - magari embedded - piuttosto che una famiglia di processori, con diverso clock, magari con diverso IPC) o magari una certa percentuale di quelle a disposizione - questo perchè certi algortmi di scheduling RT vanno in crisi se l' occupazione di risorse è maggiore del se non ricordo male, 75-80%, limite che spesso e volentieri è il sistema stesso a far rispettare, negando l' esecuzione di un processo che porterebbe l' occupazione al di sopra di esso
anche per questo un sistema RT prevede tipicamente un meccanismo di resource request che il processo usa per allocare delle risorse già note e determinate dallo sviluppatore
e già qui si nota la sostanziale differenza con un sistema general purpose, su cui tale meccanismo tipicamente, manca (in quanto effettivamente non necessario, dal momento che tipicamente quello che si cerca è proprio la saturazione - tanto, l' importante è che i task in sospeso "prima o poi" vengano eseguiti, se anche la cpu è al 100% semplicemente verranno completati in più tempo) ma su cui lo stesso sviluppo segue un approccio tipicamente opposto (e non si vede nessuno calcolare le risorse richieste a priori preoccupandosi di quanti millisecondi impiega la tale funzione ad eseguire)

ora, anche un sistema general purpose può eseguire dei task realtime ( ma a meno che le latenze del kernel non siano deterministiche, e non si giri senza paginazione su disco - che allunga i tempi di esecuzione, ma soprattutto li rende non più controllabili da chi progetta l' applicazione, motivo per cui si impone che questa giri interamente in ram - le applicazioni la certezza che le deadline non verranno sforate non la possono avere, quindi potranno essere solo task soft realtime) con un meccanismo best effort che li faccia passare prima di quelli a priorità normale e non li interrompa una volta in esecuzione - in sostanza eseguendoli a priorità maggiore del kernel stesso
questo è quello che in effetti si fa su windows, sulle versioni mainline (poi esistono progetti per il supporto più o meno completo del realtime hard) di linux e su altri sistemi general purpose
d' altra parte è anche l' unica cosa che il kernel possa fare su un sistema general purpose, ed anche l' unica che abbia senso fare, su un sistema che ha scopi, metodologie di sviluppo e comportamento di runtime radicalmente diversi da quelli di un sistema realtime
questo può in effetti operare nei contesti in cui altrimenti si userebbe un sistema general purpose (e non viceversa), ma ... eseguendo le stesse applicazioni di quest' ultimo, e non applicazioni realtime in un contesto completamente realtime (e si è visto che basta attivare la memoria virtuale e lo swap su disco per uscirne) opererebbe nè più nè meno come quest' ultimo
allora, dove starebbe il vantaggio? nella gui più reattiva?
ma per rendere più reattiva la gui non è necessario un OS realtime - che lo sia, è un pregiudizio tramandatosi a causa di sistemi non ottimizzati per il desktop e dotati di gui inefficienti - per avere una gui reattiva basterebbero meccanismi di prioritizzazione dei processi interattivi, a livello di operazioni di IO, e un threading efficiente (entrambe cose che per dire, BeOS e Haiku avevano - e soprattutto il primo è ricordato come IL sistema desktop più reattivo e leggero, eppure NON era un RTOS)
evidentemente questa gente dovrebbe ritornare a scuola
forse non vale solo per "questa gente"...
comunque sia era logico che sarebbe finita così...qnx è un sistema operativo molto molto più avanti rispetto alla massa....
più avanti, no
piuttosto, "diverso" dalla massa, per il semplice motivo che la massa è costituita da sistemi general purpose, e non RTOS
nel mondo open ci vorrebbe una cosa del genere, speriamo che haiku smuova un pò le acque
a che scopo? vuoi haiku sul suo prossimo elettrocardiografo?

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^