Je nachdem, was du vorhast, vermutlich völlig uninteressant, das zu lizensieren. Im Zweifel mal Preisanfrage machen, aber Blackberry interessiert sich vor allem für größere Kunden. Für embedded-Systeme gehen die Lizenzen für wenige € pro verkauftem Produkt bei Großkunden (
Becker Automotive wie das MMI) weg, aber für kleinere Unternehmen, die bereits für QNX entwickeln und lizensieren wollen, kann man so mit ~300€ für "Einzelstück"-Anwendungssysteme rechnen.
Einzelplatz Entwicklungsrechner ~750€, Entwicklungsumgebung ~1500€. Wohlgemerkt sind das alte Preise und das geht über Preisanfrage, ist daher ziemlich variabel, glaube aber nicht, dass sich da groß was geändert hat.
Ob man als Einzelperson zudem bei denen genug Interesse weckt, eine Lizenz für eine alte Version zu kriegen, ist die andere Sache. Nett fragen hilft erfahrungsgemäß zwar oft, aber meist eher bei kleinen Firmen, außer man kommt an einen sehr engagierten Mitarbeiter...
Die Preise richten sich halt klar an Firmen, die Geld mit QNX in Produkten verdienen wollen - leider :disappointed:
EDIT2: SSDraus, HDD rein, Update gestartet - läuft. Ohne Fehler bisher. Vielen Dank! Jemand eine Idee was die Ursache sein könnte? Wird beim Updaten irgendwas gecheckt, was es bei einer SSD nicht gibt? :-/
Vielleicht teilweise etwas technisch, aber vielleicht ist es ja interessant, auch bzgl. Sinn/Unsinn SSD im MMI:
So blöd das klingt: Höchstwahrscheinlich ist die SSD "zu schnell". Soweit ich das richtig im Kopf habe, nutzt das MMI keinen "fertigen", zugekauften Festplattencontroller-Chip, sondern einen FPGA, der auch noch andere Schnittstellen des MMI betreibt.
Das ist, vereinfacht gesagt, ein vollprogrammierbarer Logik-IC, sprich, alle Funktionen werden beim Power-On erst in den IC hochgeladen... Man entwickelt (oder kauft) quasi einen Plattencontroller als Softwarepaket. Diese sind meist ziemlich eng für ihren Einsatz zugeschnitten oder für die Geräte ausgelegt, die daran erwartet werden (bspw. eben die damals üblicherweise verbauten Automotive-Festplatten), die Treiber in QNX dann ebenso.
Es ist gut möglich, dass sich hier entweder in der Logik auf dem FPGA oder im Treiber Timingprobleme bei längeren Lese-/Schreibvorgängen ergeben: Das Problem ist hier weniger die Übertragungsrate der SSD (die liegt bei PATA-SSDs oft eher auf dem Niveau von guten Festplatten), sondern die Reaktionszeit.
4200 upm Festplatten (wie im MMI original verbaut) haben eine gewisse Latenz, die sie mechanisch nicht unterschreiten können. Für Lesevorgänge liegt diese im Mittel bei einer halben Umdrehung, also grob 7ms, selten weit darunter, weil mindestens die Spurpositionierung gemacht werden muss, selbst, wenn zufällig grade der Sektor unter dem Kopf vorbeirauscht...
Beim Schreiben landen die Daten (außer er ist ausgeschaltet) meist in einem kleinen Zwischenspeicher, bei HDD dieser Klasse so 4-8MB. Dieser verschwindet, wenn die Platte Strom verliert, daher geben Betriebssysteme, wenn sie "sicher" sein wollen, dass keine Daten verloren gehen, einen Befehl, den Speicher auf die Magnetscheibe zu leeren. Die Platte quittiert das, wenn es abgeschlossen ist. Das dauert meist mehrere umdrehungen, also kriegt der Plattencontroller und danach das Betriebssystem nach frühestens x0ms mal eine Antwort.
SSD reagieren im "schlimmsten" Fall auf diese Kommandos in unter 0.2ms. Das überfordert gerne Anwendungen, die nicht für das Verhalten von SSDs entwickelt wurden und würde auch grob erklären, warum das MMI im "Lesemodus" von Festplatte (nur navigieren) unauffällig funktioniert, es aber bei großen Schreibzugriffen knallt (Kartenupdates, Kopieren in Jukebox...)
Ich hab das Thema SSD selber durch, eben weil bei mir die Jukebox unbenutzbar wurde - und er sonst nur wenig schneller wurde. SSD-Umbau kann funktionieren (je nach Typ SSD), bei (so meine Theorie) zu schnellen SSD mit sehr kleiner Latenz aber ordentlich Probleme machen.
Ich bin am Ende auf eine Seagate 5400 upm mit 80GB umgestiegen. Die ist damit leicht schneller (~25%) und etwas größer, worum es mir eigentlich ging...