QNX kostenlos für nichtkommerzielle Nutzung verfügbar, Raspberry-Pi-Image hinzugefügt
(blackberry.qnx.com)- Entwickler von Embedded- und Echtzeitbetriebssystemen können QNX SDP 8.0 für Studium, Hobby und Prototyping kostenlos ausprobieren, wodurch die bisher stark kommerziell geprägte Einstiegshürde sinkt
- Nutzer müssen mit einem myQNX-Konto ein Lizenzformular einreichen und erhalten nach Bearbeitung der Anfrage eine QNX-Softwarelizenz für nichtkommerzielle Nutzung
- Der Umfang umfasst QNX SDP 8.0, QNX Developer Desktop und QNX Hypervisor und reicht damit vom Erlernen des OS über self-hosted Entwicklung bis zu Virtualisierungsexperimenten
- Als Einstiegsressourcen werden ein Quick Start Guide, ein QNX-8.0-Image für Raspberry Pi, QNX-Everywhere-Videos und der Self-Hosted Developer Desktop Guide bereitgestellt
- Die kostenlose Lizenz ist auf Bildung, persönliche Projekte und das Erlernen von RTOS beschränkt; für Evaluierung und Entwicklung zu kommerziellen Zwecken muss eine separate 30-Tage-Evaluierungslizenz beantragt werden
Nichtkommerzielle QNX-Entwicklungsumgebung verfügbar
- QNX Everywhere ist ein Programm, mit dem Studierende, Hobbyentwickler und Prototyper QNX-Software kostenlos für nichtkommerzielle Zwecke nutzen können
- Angeboten werden QNX’ Betriebssystem der nächsten Generation, Entwicklungstools und Echtzeitfunktionen, die sich für Lernen, Experimente und den Bau leistungsfähiger Embedded-Projekte nutzen lassen
- Öffentlich genannte Zahlen sind 15K+ Downloads von QNX-Everywhere-Lizenzen, 6K+ registrierte Lernende in Online-Kursen und 100+ kooperierende akademische Einrichtungen
Ablauf der Lizenzbeantragung
- Für eine nichtkommerzielle Lizenz ist ein myQNX-Konto erforderlich
- Wer bereits ein Konto hat, meldet sich an
- Wer QNX zum ersten Mal nutzt, erstellt ein myQNX-Konto
- Nach dem Login startet man die Anfrage, indem man die Lizenzdaten im QNX-Everywhere-Lizenzformular eingibt
- Nach Abschluss der Bearbeitung erhält man eine QNX-Softwarelizenz für die nichtkommerzielle Nutzung
- Es kann nach der Anfrage bis zu 1 Stunde dauern, bis die Lizenz im myQNX-Profil angezeigt wird
Enthaltene Plattformen und Tools
- QNX SDP 8.0 ist die grundlegende Entwicklungsplattform für SoCs der nächsten Generation
- Enthält das QNX Operating System der nächsten Generation
- Stellt eine Architektur in den Vordergrund, die darauf ausgelegt ist, künftige Fortschritte bei Silizium zu nutzen
- Zielt darauf ab, in rechenintensiven Systemen im gesamten IoT konsistente Echtzeitleistung bereitzustellen
- Enthält eine aktualisierte Toolchain, neue Utilities für Debugging und Profiling sowie Open-Source-Utilities
- QNX Everywhere umfasst Zugriff auf Folgendes
- QNX SDP 8.0: leistungsstarke, safety-ready Microkernel-RTOS-Plattform
- QNX Developer Desktop: self-hosted Desktop zum Erstellen von Anwendungen unter QNX OS 8.0
- QNX Hypervisor: deterministischer Hypervisor für Mixed-Criticality-Systeme
Bildung, Community und Open Source
- QNX bietet kostenlose Online-Kurse für Entwickler von QNX OS an
- Entwickler können sich mit QNX-Ingenieuren und der Online-Entwickler-Community vernetzen, Probleme lösen, Ideen diskutieren und an Open-Source-Projekten zusammenarbeiten
- Da es ein POSIX-kompatibles OS ist, lässt sich ein großer Teil der Software für POSIX-Betriebssysteme mit wenig oder gar keinen Änderungen für QNX kompilieren
- QNX veröffentlicht den Quellcode von Open-Source-Ports gemäß den ursprünglichen Lizenzen und pflegt nutzbare Ports in einem GitHub repository
- Ports, Testniveau und Hosting-Details sind im Open-Source Dashboard einsehbar
Einstieg mit Dokumentation und Raspberry-Pi-Image
- Die QNX-Everywhere-Dokumentation bietet die Tools und Anleitungen, die nötig sind, um von der ersten Anwendung bis zu fortgeschrittenen QNX-Lösungen zu bauen
- Die bereitgestellten Ressourcen sind
- QNX SDP 8.0 Quick Start Guide: Anleitung für den Einstieg in die QNX-Entwicklung
- QNX Quick Start Target Image for Raspberry Pi: QNX-8.0-Quickstart-Target-Image für Raspberry Pi
- Get Started With QNX Everywhere: Einstiegsvideos zu QNX Everywhere
- Self-Hosted Developer Desktop Guide: Leitfaden zum self-hosted Developer Desktop
- Nutzer eines Raspberry Pi 5 können ein vorbereitetes QNX-SDP-8.0-Image flashen und verwenden
- Das Image enthält mehrere Open-Source-Demoanwendungen
- Die Demoanwendungen können geklont, verändert und neu gebaut werden
Nutzungsbedingungen und Ausschlüsse
- Die kostenlose Lizenz richtet sich an private, nichtkommerzielle Nutzer der QNX Software Development Platform 8.0
- Erlaubt sind Bildungszwecke, persönliche Projekte sowie Aktivitäten ohne Umsatzgenerierung oder Geschäftsbetrieb
- Nichtkommerzielle Nutzung umfasst akademische Umgebungen, Hobbyentwickler und Lernende im Bereich Echtzeitbetriebssysteme
- Evaluierung oder Entwicklung zu kommerziellen Zwecken ist nicht enthalten
- Kommerzielle Aktivitäten umfassen Umsatzgenerierung oder Geschäftsbetrieb
- Eine kommerzielle 30-Tage-Evaluierungslizenz muss separat beantragt werden
- QNX SDP 7.1 ist in diesem Programm nicht enthalten
- QNX SDP 8.0 wird für Softwareplattformen der nächsten Generation auf SoC-Basis mit 4 oder mehr CPU-Kernen bereitgestellt
Mehrfachinstallationen in Bildungseinrichtungen
- Wer mehrere Workstations in einem Labor oder Klassenraum einrichten möchte, kann über das Programm QNX in Education eine Mehrbenutzerlizenz erhalten
- Zum Umfang gehören QNX Software Development Platform 8.0 und QNX Software Development Platform 7.1
- Wenn jeweils nur eine Instanz installiert wird, wird die Nutzung der QNX-Everywhere-Lizenz empfohlen
Fehlerbehebung bei Konto und Lizenz
- Bei Login-Problemen nach Registrierung eines neuen myQNX-Kontos soll man sich an myqnx@blackberry.com wenden
- Der Status von Lizenzen und Produktbereitstellungen kann im myQNX License Manager geprüft und akzeptiert werden
- Im Abschnitt Registered Products des myQNX-Kontoprofils werden Lizenzschlüssel, Seriennummern, Lizenzzertifikate und Lizenzmanager für die bereitgestellten Produkte angezeigt
- Um das QNX Software Center herunterzuladen, muss dem myQNX-Nutzer eine QNX-Produktlizenz zugewiesen sein
1 Kommentare
Meinungen auf Hacker News
Es wäre schön, wenn man dem trauen könnte, aber QNX wurde in der Vergangenheit schon zweimal „geöffnet“ und danach wieder geschlossen.
Vor der ersten Rücknahme nahmen Open-Source-Projekte QNX häufig als Build-Target auf; es gab Target-Support für Firefox und Eclipse unter QNX, und auch GCC sowie GNU-Command-Line-Tools ließen sich bauen.
Es gab auch eine Desktop-Umgebung namens Photon, und beim Bau eines Fahrzeugs für die DARPA Grand Challenge nutzte ich sie drei Jahre lang als primären Desktop.
Doch nachdem Harman 2004 QNX übernommen hatte, verschwand all das. 2007 wurde der Source erneut geöffnet, sodass man sogar in den Microkernel hineinschauen und ihn bauen konnte, aber es war keine öffentliche Lizenz.
Als RIM 2010 QNX übernahm, wurde der Source ohne jede Vorwarnung geschlossen; die gesamte Open-Source-Entwicklung rund um QNX kam zum Erliegen, und auch das Vertrauen der Community ging verloren.
Auch die Vertragsbedingungen sind ein Problem: Unter http://www.qnx.com/download/feature.html?programid=51624 heißt es: „TERMINATION. This Agreement and licenses granted hereunder may be terminated by either Party upon written notice to the other Party“ – QNX kann also jederzeit den Stecker ziehen.
Wenn QNX es ernst meint, sollte es sich meiner Meinung nach am Lizenzmodell der Unreal Engine orientieren: Source herunterladen, nach Belieben nutzen, kostenlos bis zu 1 Mio. US-Dollar Produktumsatz, danach erhält Epic 5 % Royalties: https://cdn2.unrealengine.com/UnrealEngine/faq/UnrealEngineE...
Auch Piraterie ist kein großes Problem, denn sobald ein Spiel nennenswerte Umsätze erzielt, fällt es genug auf, dass die Lizenzverantwortlichen davon erfahren.
Wenn QNX die Verbreitung steigern will, sollte man die Bedingungen von Epic der Rechtsabteilung und dem Management vorlegen und das Umsatzwachstum der Unreal Engine mit QNX vergleichen.
Wie ich es früher schon einem QNX-Vertriebsmitarbeiter gesagt habe: Das Problem von QNX ist nicht Piraterie, sondern dass es ignoriert wird.
Jegliche Open-Source-Aktivität war untersagt, obwohl viele von uns damals aktiv an Open Source mitarbeiteten. Ich hatte sogar einmal für die Eclipse Foundation gearbeitet.
Ein Freund, der Romane schrieb, bekam zu hören, er brauche jedes Mal eine schriftliche Genehmigung, wenn er einen Text veröffentlichen oder publizieren wolle.
Deutsche Ingenieure wurden gedrängt, einen Vertrag zu unterschreiben, dessen verbindliche Sprache Englisch war, obwohl eine deutsche Übersetzung beigefügt war; am Ende gingen viele von uns einfach.
Am stärksten ist mir in Erinnerung geblieben, wie das aus Kanada angereiste Transition-Team sagte, RIM-Mitarbeiter arbeiteten in dunklen Betonverliesen, und wir könnten uns glücklich schätzen, weiter die schönen Büros in München nutzen zu dürfen.
In der DNA dieses Unternehmens schien eine offene Arbeitsweise völlig fremd zu sein, und ich würde dem nicht im Geringsten vertrauen.
Hobbyentwickler sowie freie und Open-Source-Projekte würden ein GPLv3-Betriebssystem gerne nutzen, während traditionelle große kommerzielle Kunden aus der Automobil- und Embedded-Branche wohl nicht die GPLv3-Pflicht wollen, Nutzern die Installation eigener Firmware zu ermöglichen, und daher weiter bezahlen würden.
Das könnte für alle ein Gewinn sein.
Das ist keine Rechtsberatung; die Auslegung der Lizenz muss jeder selbst vornehmen.
Vor der Veröffentlichung von BB10 hatte ich ein längeres Gespräch mit Ingenieuren; soweit ich mich erinnere, musste man damals Zugang zum gesamten Blackberry SDK beantragen und außerdem ein NDA unterschreiben.
Android und iOS waren dagegen bereits in vollem Gange, und die Plattformen, die das Schreiben von Apps leicht machten, waren die erfolgreichen.
Blackberry wirkt organisatorisch unfähig, mit der Community und solchen Beziehungen umzugehen. In der Führungsebene steckt ein Carrier-artiges „wir gegen die“-Denken, das – ausdrücklich oder implizit – nach unten durchsickert.
Nach dem Scheitern von BeOS habe ich mit QNX herumgespielt und dafür entwickelt, und ich mochte es so sehr, dass ich es auf meiner Haupt-Entwicklungsmaschine Vollzeit nutzte.
Als es dann geschlossen wurde, habe ich mir daran ordentlich die Finger verbrannt, und seitdem fasse ich keine geschlossene Entwicklungsplattform mehr an.
Wenn ich mir die Lizenz heute ansehe, hat sich kein bisschen etwas geändert, und inzwischen ist QNX außerhalb seiner bestehenden Märkte weitgehend irrelevant geworden.
Sich heute für QNX zu entscheiden, wirkt unklug. Es gibt inzwischen gute Alternativen, und alle haben offene Lizenzen.
Inzwischen gibt es auch https://arstechnica.com/gadgets/2024/09/real-time-linux-is-o...
Mit Linux muss man keine Lizenzdiskussion führen und muss auch nicht befürchten, plötzlich hinterrücks getroffen und ausgesperrt zu werden.
Das Verbot kommerzieller Nutzung ist furchtbar. Ich mache gerade mit ArangoDB etwas Ähnliches durch: Das Produkt ist gut, aber ich habe weder Budget für von ihnen verwaltete Cloud-Instanzen noch dafür, mit dem Vertrieb über eine kommerzielle Lizenz zu verhandeln.
Ich nutze es in mehreren Systemen, und eines davon ist inzwischen ungefähr bei 80 % der Datenbankgröße angelangt, die „zu groß für kostenlose Nutzung“ ist, aber ich weiß nicht, ob daraus am Ende Open Source, ein Produkt oder ein System wird, das direkt Geld verdient.
Deshalb ist der kurzfristig einfachere Weg nicht, mit Leuten zu reden, die mein Geschäftsmodell vielleicht nicht erlauben, sondern zu PostgreSQL zu migrieren.
Die Entwicklerbedingungen für die nichtkommerzielle Nutzung von QNX 8.0 sind direkt hier zu finden: https://support7.qnx.com/download/download/51624/BB_QNX_Deve...
Dies ist keine Rechtsberatung und auch keine umfassende Prüfung oder zusammenfassende Auslegung dieser Lizenz. Bevor man auf Grundlage des Folgenden handelt, sollte man sich fachkundigen Rat von einem Anwalt holen.
Die Bedingungen beginnen mit einer Klausel in dem Sinne, dass der Nutzer keine Gelegenheit hatte, sie zu prüfen und ihnen zuzustimmen, bevor er sich selbst, sein Unternehmen oder seine Institution bindet; in den USA könnte das offenbar das gesamte Dokument unwirksam machen, daher ist es sicherer, sie vor der Nutzung mit einem Anwalt zu prüfen.
Im akademischen Bereich sind nur Studierende und Lehrkräfte der jeweiligen Institution berechtigt, und die Nutzung dieser Lizenz könnte aus Sicht der Rechtsabteilung so wirken, als hätte man im Namen des Arbeitgebers einen verbindlichen Vertrag unterzeichnet.
Man sollte sicherstellen, dass man nicht durch Open-Source-Beitragende haftbar wird oder Gefahr läuft, entlassen zu werden, weil man sich fälschlich als zeichnungsberechtigte Person der Institution ausgegeben hat.
Cloud-Nutzer sind laut Bedingungen auf AWS beschränkt; wer es auf GCP, Heroku oder anderen Server-Instanzen nutzt, die nicht unter eigener vertraglicher Kontrolle stehen, könnte lizenzkostenpflichtig werden.
Das hier erlaubte „Open Source“ ist ausschließlich die OSI-Definition; wer Software unter einer restriktiven nichtkommerziellen Lizenz vertreibt, kann die nichtkommerzielle QNX-Lizenz nicht nutzen.
Die Klausel zu „High Risk“ verbietet die Entwicklung von Anwendungen, die der Gesellschaft schaden könnten, daher könnten auch Social Apps ausgeschlossen sein. Man sollte aufpassen, diese Klausel nicht zu verletzen, wenn man eine virale Anwendung baut.
Es werden alle identifizierbaren Seriennummern sämtlicher Hardware erfasst und gespeichert, die im Zusammenhang mit diesem Produkt verwendet wird.
Die nichtkommerzielle Lizenz kann jederzeit ohne Bedingungen beendet werden, selbst wenn man die Bedingungen gewissenhaft eingehalten hat; dann muss man möglicherweise eine nicht definierte „Zertifizierung“ zu unbekannten Kosten vorlegen, dass aller erhaltene QNX-Code gelöscht wurde.
Wenn ein Twitter-Client abstürzt, wird niemand verletzt oder getötet.
Angesichts eines ausgereiften Real-Time Linux frage ich mich, für welches Projekt man QNX überhaupt verwenden sollte. Soll man sich wirklich darum kümmern, nur um dann durch eine plötzliche Lizenzänderung überrumpelt zu werden?
Aus Gründen der Niedlichkeit und akademischen Neugier habe ich QNX früher schon einmal verwendet.
Aber wenn ich das nächste Mal ein SoC und das dazugehörige BSP für ein Projekt auswähle, werde ich nicht nach QNX suchen. Ich würde eher die mitgelieferte FreeRTOS-Distribution verwenden oder die Android-Build-Tools installieren und APKs in einen seltsamen Android-Fork schieben.
Im Automobil- oder Medizinbereich ist das eine andere Geschichte, aber auch dort holen die Wettbewerber weiter auf, und die Real-Time-Änderungen in Linux werden es noch schwieriger machen.
Wir haben nicht mehr 2010. Es gibt viele Optionen, und während QNX hinter unklaren und nervigen Lizenzanforderungen verharrte, haben Dutzende Firmen Alternativen entwickelt. Einige davon sind ziemlich groß, und manche sind sogar ins All geflogen.
Wenn QNX jetzt ernst genommen werden will, reicht es nicht, „die Türen zu QNX wieder ein Stück weit wie früher zu öffnen“.
Wenn es nicht vollständig Open Source auch für kommerzielle Nutzung ist, habe ich kein Interesse daran. Wenn die Tools und der BSP-Support den Zeitaufwand wert sind, könnte ich eine Lizenz im Epic-Stil akzeptieren, aber ich habe überhaupt kein Interesse daran, Lizenzgebühren zu zahlen, nur um überhaupt loszulegen.
Das Produkt ist zur Commodity geworden und ist jetzt eher ein Kuriosum. Der einzige Weg, genug aktive Entwicklung und Adoption zu bekommen, ist, ein Community-Projekt zu werden.
Nicht allen ist wichtig, ob etwas frei und Open Source ist, und es ist nicht überraschend, dass Menschen bei solchen Fragen unterschiedlich gewichtet entscheiden.
Von den Betriebssystemen, die ich Anfang der 2000er ausprobiert habe, waren QNX und BeOS die einzigen, die einen alten Single-Core-Pentium aus der Mitte der 90er wirklich gut und flott wirken ließen
Es war deutlich besser als jede Windows-Version oder Linux
In beiden Fällen lag das meiner Ansicht nach vor allem am Scheduler und am deutlich besseren Multimedia-Stack
Ich habe mir immer gewünscht, dass sich die Betriebssysteme der Zukunft so anfühlen würden; am nächsten kommt dem vermutlich iOS, wobei es dafür den Trick nutzt, Prozesse ständig abzuschießen. Die Zukunft ist nicht besonders toll
Die Betriebssysteme derselben Zeit hatten damals einen riesigen globalen Lock
Bei BeOS lag das Preemption-Intervall, wenn ich mich richtig erinnere, bei 750 ms oder 3 ms; sicher bin ich mir nicht. Es war aber kürzer als die 20 ms und später 10 ms von Linux und Windows, und deshalb hat man den Unterschied wohl gespürt
Jahrzehnte später haben die meisten Betriebssysteme bei feingranulareren Locks im Kernel-Space aufgeholt, aber die Preemption-Intervalle unterscheiden sich wegen der Debatte Durchsatz versus Latenz weiterhin. Skriptbasierte Betriebssystem-Benchmarks messen den Gesamtdurchsatz, nicht die GUI-Reaktionsfähigkeit
Medienpuffer, die von kleinen Puffergrößen profitieren, sind ein gutes Beispiel: Auch wenn der Durchsatz sank, bemerkten Musiker die bessere Reaktionsfähigkeit von BeOS, weshalb es den Spitznamen „Media OS“ bekam
Auch im GUI-Bereich bietet der App-Server von BeOS/Haiku eine verteilte Arbeitslast als andere Desktop-Umgebungen. Jedes Fenster bekommt einen eigenen Thread, die App bekommt ebenfalls einen eigenen Thread, und App sowie Application-Server haben je App und Fenster einen Thread, damit sie nicht blockieren, während sie auf das Parsen langsamer App-Nachrichten warten
Daher hat selbst eine minimale BeOS-App mit einem grafischen „Hello World“-Fenster vier Threads. Selbst wenn die App beschäftigt ist, fühlt sich der Rest des Systems weiterhin reaktionsschnell an
Dafür gibt es Kosten beim Durchsatz und bei der Komplexität der App-Entwicklung, besonders stark bei portierten Apps
Haiku muss Qt-/Gtk-/Toolkit-Nachrichten aus mehreren Fenstern in eine einzelne Message-Queue einsortieren, um Multithreading-Bugs zu vermeiden. Denn in der ursprünglichen Umgebung war die App-Message-Loop nicht multithreaded
Durch dieses Sortieren braucht Haiku zusätzliche Lock-/Unlock-Aufrufe, auch wenn sie eigentlich nicht nötig wären, etwa bei Nachrichten an dasselbe Fenster
Haiku-native Apps dagegen laufen butterweich. Hier ist ein Screenshot des Medo-Videoeditors, bei dem alle Fenster in eigenen Threads laufen: https://raw.githubusercontent.com/smallstepforman/Medo/refs/...
Auf modernen Systemen läuft diese App butterweich, was für einen Videoeditor fast ketzerisch ist. Die verlinkte Haiku-App habe ich geschrieben
Ich habe Android aufgegeben, als nicht einmal Samsung ernsthaft versuchte, die Reaktionsfähigkeit seiner Telefone zu verbessern
Es ist gut, dass Apple konsequent Wert auf Reaktionsfähigkeit legt; dadurch bekommen auch Google, Samsung und Microsoft einen Anreiz, ihre aufgeblähten Produkte zu überarbeiten
Welches heutige Betriebssystem kommt dieser Spritzigkeit am nächsten? Haiku OS?
Ich benutze ein M1 MacBook gern, aber manchmal fühlt es sich nicht ganz ausreichend an
Ein weiteres Beispiel: SGI IRIX hatte einen ungewöhnlich guten Scheduler. Ich habe eine Zeit lang eine 30-MHz-Maschine benutzt, und der Desktop fühlte sich ziemlich flott an
Eines Tages kompilierte ich AMP und gab ihm eine Liste von MP3s, die größtenteils 192 kbps hatten; zur Einordnung: Dieses Programm konnte auch 256 kbps ohne Aussetzer decodieren
Die Dateien lagen auf einem NFS-Share, und als ich gr_osview laufen ließ, lag die CPU-Auslastung bei 95 %, trotzdem reagierte der Dateimanager und die Musik stockte nicht
Schon das Decodieren von MP3s mit hoher Bitrate über 192 kbps auf 30 MHz war beeindruckend
Dass es trotz vollständigem X-Window-System-Desktop und Wiedergabe von Dateien von einem NFS-Share reaktionsfähig blieb, zeigt einen schlanken und starken Netzwerk-Stack und Scheduler, der auch auf schwacher Hardware gut funktionierte
Es war IRIX 5.3 auf einer Indigo Elan
Ein Freund und ich mochten Betriebssysteme, deshalb ließen wir BeOS auf einem alten Pentium 90 laufen, und wie oben gesagt: Es war flott
Auch Linux trug seinen Teil bei. Nach einem Wasserschaden war dieser Pentium 90 nicht mehr stabil, und weil er RAM ohne Parität nutzte, wurde Windows NT allmählich seltsam und endete immer wieder in Bluescreens
Aus Spaß installierte ich Red Hat 5.2 darauf, und es lief gut. Im Systemlog erschienen jede Sekunde viele Einträge, und man konnte eine X-Konsole öffnen und einfach zusehen, wie sie vorbeiliefen
Die Maschine hat zum Spaß auch ein paar Wochen lang die Firmenwebseite ausgeliefert. Das waren gute Zeiten
Um ein Detail zu ergänzen: Der QNX-Quellcode war von 2007 bis zur Übernahme durch RIM/BlackBerry im Jahr 2010 zugänglich
Gibt es Pläne, künftig wieder Zugang zum QNX-Quellcode anzubieten?
https://www.qnx.com/news/pr_2471_1.html
Wir hören von Kunden wie auch von der Community, dass ihnen das wichtig ist. Bleibt dran
Das frühere Unternehmen baute hochverfügbare Active/Standby-Router für Mobilfunknetze und verwendete QNX als Betriebssystem. Diese Fähigkeiten sind immer noch beeindruckend.
Meine Erinnerung ist etwas verschwommen, aber wir ließen QNX auf dem Control-Plane-Prozessor laufen, und es unterstützte nativ, über das interne Router-Netzwerk Prozesse auf entfernten Prozessoren zu starten.
Das heißt, die Low-Level-Interprozesskommunikation konnte IP verwenden, und QNX’ IPC war für die hochverfügbare Failover-Funktion unverzichtbar.
Großartig war auch, dass Gerätetreiber User-Space-Prozesse waren und bei einem Absturz neu gestartet werden konnten. Da wir gerade einen Netzwerktreiber entwickelten, kam das gelegentlich tatsächlich vor.
Besser war auch, dass Geräte tatsächlich im /dev/-Tree sichtbar waren – anders als unter Linux, wo Netzwerkgeräte eine Ausnahme sind und nicht wirklich sauber im /dev/-Tree erscheinen.
Eine amüsante Anekdote: Einmal gab es ein Problem, weil ich versehentlich einen IPC-Rückgabewert mit const versehen hatte; mein Prozess starb zwischen der IPC-Funktion von QNX und meiner eigenen Funktion.
Ich habe tagelang debuggt, und mit dem damaligen C-/User-Space-Debugger ließ sich der Fehler nicht finden.
Die Line Cards liefen ebenfalls unter Linux, programmierten aber nur den ASIC so, wie es die Control Plane vorgab.
Solche Funktionen waren nicht wirklich relevant, und IPC konnte man per HTTP oder auf jede gewünschte Weise machen.
@JohnAtQNX Könnt ihr bei den Downloads auf der Website die Einschränkung entfernen, dass alles ein Konto erfordert, und auch den Lizenzmechanismus von qcc abschaffen?
Das würde sehr dabei helfen, Hobbyentwickler zum Ausprobieren zu ermutigen.
Die Einnahmen kommen vermutlich aus großen Lizenzverträgen und einer Lizenzgebühr pro Gerät.
Wenn man CI/CD-Teams verärgert, die die QNX-Produktfamilie unterstützen müssen, gefährdet man diese Einnahmequelle.
Es ist gut, dasselbe auch von außen zu hören; ich werde es wieder auf den Tisch bringen und nach und nach vorantreiben.
Ich hasse es wirklich, für jede neue Sache schon wieder ein neues Login anlegen zu müssen.
Dasselbe gilt für Newsfeeds: Fast die Hälfte der Nachrichtenseiten verlangt ein Login, obwohl sie „kostenlos“ sind. In dem Fall ist es immerhin leichter, denselben Artikel anderswo zu finden.
Ich erinnere mich noch daran, wie beeindruckt ich von der QNX-Demo auf einer einzigen Diskette war, die sogar einen Webbrowser enthielt. Sie war wirklich schnell.
Ich hoffe, das klappt. Ich kann mir nur vorstellen, was für ein gordischer Knoten es ist, alle rechtlichen Fragen zu klären, um tatsächlich etwas zu öffnen.
Wie andere schon sagten, sind alle vorsichtig, nachdem man sich zweimal die Finger verbrannt hat, aber an QNX gibt es viel, das Spaß macht; hoffentlich bekommt es diesmal Schwung.
Seitdem hatte ich QNX gegenüber eine gewisse positive Grundhaltung, aber die zwischenzeitlichen Eigentümerwechsel und Änderungen am offenen/kommerziellen Status haben mich immer auf Abstand gehalten.
Leider wirkt auch diese „Öffnung“ vertraut, und ich gehe davon aus, dass sie wieder zurückgenommen wird, solange keine wirklich freie GPL-Lizenz und keine ausreichend große freie Open-Source-Community entstehen, um einen Fork am Leben zu halten.
Ich finde den mutigen Versuch gut. QNX habe ich seit Langem mit Interesse aus der Distanz verfolgt, war aber in den meisten Fällen kein potenzieller Nutzer.
Ein guter nächster Schritt wäre eine Reihe von Blogposts, die typische Hobbyprojekt-Arten auswählen und erklären, wie man in diesem Kontext die Stärken von QNX nutzen kann.
Ich arbeite außerdem bei einer gemeinnützigen Organisation, die Küstenschutzforschung betreibt; dort gibt es einige Leute, die eigene Hardware bauen. Könnte es auch für uns nützlich sein?
Wir bei Rizin möchten die QNX-Unterstützung unseres freien Open-Source-Frameworks für Reverse Engineering und Debugging verbessern.
Unterstützung gibt es bereits[1][2][3][4], aber wir können sie nicht zuverlässig testen.
Schön wäre es, wenn ein QEMU-Image direkt bereitgestellt würde, so wie Windows sofort eingeschränkte VMs zum Testen anbietet[5].
[1] https://github.com/rizinorg/rizin/tree/dev/librz/bin/format/...
[2] https://github.com/rizinorg/rizin/blob/dev/librz/bin/p/bin_q...
[3] https://github.com/rizinorg/rizin/blob/dev/librz/debug/p/deb...
[4] https://github.com/rizinorg/rizin/tree/dev/subprojects/rzqnx
[5] https://developer.microsoft.com/en-us/windows/downloads/virt...
Ich verstehe aber, dass ein One-Click-Download wie bei den Windows-Images einfacher wäre, und nehme dieses Feedback mit.
Wenn wir auf andere Weise helfen können, QNX-Support zu ermöglichen, schreib mir per DM oder an qnxcommunityengagement at qnx dot com.