QNX ने गैर-व्यावसायिक उपयोग के लिए मुफ्त उपलब्धता शुरू की, और Raspberry Pi इमेज जोड़ी

 (blackberry.qnx.com)
1 पॉइंट द्वारा GN⁺ 2024-11-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • embedded और real-time OS डेवलपर्स अब QNX SDP 8.0 को छात्र, hobby, और prototype उपयोग के लिए मुफ्त में आज़मा सकते हैं, जिससे पहले की commercial-केंद्रित पहुंच बाधा कम होती है
  • उपयोगकर्ताओं को myQNX account के साथ license form जमा करना होगा, और request process होने के बाद non-commercial QNX software license मिलेगा
  • उपलब्ध दायरे में QNX SDP 8.0, QNX Developer Desktop, और QNX Hypervisor शामिल हैं, जिससे OS सीखने से लेकर self-hosted development और virtualization प्रयोग तक काम किया जा सकता है
  • शुरुआती resources के रूप में Quick Start Guide, Raspberry Pi के लिए QNX 8.0 image, QNX Everywhere वीडियो, और Self-Hosted Developer Desktop Guide दिए गए हैं
  • मुफ्त license केवल education, personal project, और RTOS learning तक सीमित है; commercial purpose evaluation·development के लिए अलग 30-दिन का evaluation license आवेदन करना होगा

गैर-व्यावसायिक QNX development environment उपलब्ध

  • QNX Everywhere एक ऐसा प्रोग्राम है जो छात्रों, hobby developers, और prototypers को QNX software को गैर-व्यावसायिक उद्देश्यों के लिए मुफ्त में उपयोग करने देता है
  • इसमें QNX का अगली पीढ़ी का OS, development tools, और real-time features शामिल हैं, जिनका उपयोग learning, experimentation, और high-performance embedded projects बनाने में किया जा सकता है
  • सार्वजनिक आँकड़ों के अनुसार, QNX Everywhere license downloads 15K+, registered online training learners 6K+, और partner academic institutions 100+ हैं

license आवेदन प्रक्रिया

  • non-commercial license पाने के लिए myQNX account आवश्यक है
    • यदि आपका existing account है, तो login करें
    • यदि आप पहली बार QNX उपयोग कर रहे हैं, तो myQNX account बनाएं
  • login के बाद QNX Everywhere license form में license data भरकर request शुरू करें
  • request process पूरा होने पर गैर-व्यावसायिक उपयोग के लिए QNX software license मिलता है
  • request के बाद license को myQNX profile में दिखने में अधिकतम 1 घंटा लग सकता है

शामिल platforms और tools

  • QNX SDP 8.0 अगली पीढ़ी के SoC के लिए एक foundational development platform है
    • इसमें अगली पीढ़ी का QNX Operating System शामिल है
    • यह ऐसी architecture पर जोर देता है जिसे future silicon advancements का लाभ उठाने के लिए डिजाइन किया गया है
    • इसका लक्ष्य IoT के compute-intensive systems में लगातार real-time performance देना है
    • इसमें upgraded toolchain, debugging·profiling के लिए नए utilities, और open source utilities शामिल हैं
  • QNX Everywhere में निम्न access शामिल है
    • QNX SDP 8.0: high-performance, safety-ready microkernel RTOS platform
    • QNX Developer Desktop: QNX OS 8.0 पर applications बनाने के लिए self-hosted desktop
    • QNX Hypervisor: mixed-criticality systems के लिए deterministic hypervisor

शिक्षा, community, और open source

  • QNX, QNX OS developers के लिए free online training courses उपलब्ध कराता है
  • developers, QNX engineers और online developer community से जुड़ सकते हैं, और problem solving, idea discussion, तथा open source project collaboration कर सकते हैं
  • यह एक POSIX-compatible OS है, इसलिए POSIX operating systems के लिए बने काफी software को लगभग बिना बदलाव के QNX के लिए compile किया जा सकता है
  • QNX open source ports का source code उनकी मूल license शर्तों के अनुसार प्रकाशित करता है, और developers के उपयोग के लिए ports को GitHub repository में बनाए रखता है
  • ports, test levels, और hosting details Open-Source Dashboard पर देखे जा सकते हैं

documentation और Raspberry Pi image के साथ शुरुआत

  • QNX Everywhere documentation पहले application से लेकर advanced QNX solutions तक बनाने के लिए आवश्यक tools और guidance प्रदान करता है
  • उपलब्ध resources इस प्रकार हैं
  • Raspberry Pi 5 उपयोगकर्ता तैयार QNX SDP 8.0 image को flash करके उपयोग कर सकते हैं
    • image में कई open source demo applications शामिल हैं
    • demo applications को clone, modify, और rebuild किया जा सकता है

उपयोग की शर्तें और अपवाद

  • मुफ्त license QNX Software Development Platform 8.0 के लिए व्यक्तिगत गैर-व्यावसायिक उपयोगकर्ताओं हेतु है
  • अनुमत उपयोग में education purpose, personal projects, और ऐसी गतिविधियाँ शामिल हैं जिनमें revenue generation या business operation नहीं होता
  • गैर-व्यावसायिक उपयोग में academic environments, hobby developers, और real-time operating system learners शामिल हैं
  • commercial purpose evaluation या development इसमें शामिल नहीं है
    • commercial activities में revenue generation या business operation शामिल है
    • commercial 30-day evaluation license के लिए अलग से आवेदन करना होगा
  • QNX SDP 7.1 इस प्रोग्राम में शामिल नहीं है
    • QNX SDP 8.0, 4 या उससे अधिक CPU cores वाले SoC-आधारित अगली पीढ़ी के software platform के लिए उपलब्ध कराया गया है

शैक्षणिक संस्थानों में multiple installations

  • यदि lab या classroom में कई workstations सेट करने हों, तो QNX in Education प्रोग्राम के माध्यम से multi-user license लिया जा सकता है
    • इसमें QNX Software Development Platform 8.0 और QNX Software Development Platform 7.1 शामिल हैं
  • यदि एक समय में केवल एक instance install करना है, तो QNX Everywhere license उपयोग करने की सिफारिश की जाती है

account और license समस्या समाधान

  • नया myQNX account register करने के बाद login समस्या हो तो myqnx@blackberry.com पर संपर्क करें
  • license और product deployment status को myQNX License Manager में देखा और स्वीकार किया जा सकता है
  • myQNX account profile के Registered Products section में deploy किए गए products के अनुसार license key, serial number, license certificate, और license manager दिखते हैं
  • QNX Software Center डाउनलोड करने के लिए myQNX user को QNX product license assigned होना चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-11-08
Hacker News टिप्पणियाँ

  • अगर इस पर भरोसा किया जा सकता, तो अच्छा होता, लेकिन QNX पहले भी दो बार “खुलकर” फिर बंद हो चुका है
    पहली बार वापस लेने से पहले open source projects अक्सर QNX को build target में शामिल करते थे, QNX के लिए Firefox और Eclipse target support था, और GCC तथा GNU command-line tools भी build किए जा सकते थे
    Photon नाम का एक desktop environment भी था, और DARPA Grand Challenge वाहन बनाते समय मैंने इसे 3 साल तक अपने मुख्य desktop के रूप में इस्तेमाल किया
    लेकिन 2004 में Harman द्वारा QNX के अधिग्रहण के बाद यह सब गायब हो गया, और 2007 में source फिर खोला गया ताकि microkernel तक देखा और build किया जा सके, लेकिन वह public license नहीं था
    2010 में RIM ने QNX का अधिग्रहण किया तो बिना किसी चेतावनी के source फिर बंद कर दिया गया, QNX से जुड़ा सारा open source development रुक गया, और community का भरोसा भी खत्म हो गया
    contract terms भी समस्या हैं: http://www.qnx.com/download/feature.html?programid=51624 में लिखा है, “TERMINATION. This Agreement and licenses granted hereunder may be terminated by either Party upon written notice to the other Party”, यानी QNX इसे कभी भी समाप्त कर सकता है
    अगर QNX सच में गंभीर है, तो इसे Unreal Engine-शैली के license का रास्ता अपनाना चाहिए। source डाउनलोड करो और खुलकर इस्तेमाल करो, product revenue 10 लाख डॉलर तक free, उसके बाद Epic 5% royalty ले: https://cdn2.unrealengine.com/UnrealEngine/faq/UnrealEngineE...
    piracy भी बहुत बड़ी समस्या नहीं है, क्योंकि अगर कोई game अर्थपूर्ण revenue कमा रहा है तो वह इतना दिखने लगता है कि license प्रभारी को पता चल ही जाएगा
    अगर QNX adoption बढ़ाना चाहता है, तो Epic की terms sheet को legal team और management के पास ले जाकर Unreal Engine की revenue growth की तुलना QNX से करनी चाहिए
    जैसा मैंने पहले QNX sales प्रतिनिधि से कहा था, QNX की समस्या piracy नहीं, बल्कि लोगों द्वारा उसे नज़रअंदाज़ किया जाना है

    • मैं 2011 में RIM/Blackberry द्वारा अधिग्रहित एक German startup में काम करता था, और कंपनी ने सभी कर्मचारियों से नए contract पर हस्ताक्षर करवाने की कोशिश की जिसमें मौजूदा role और salary बरकरार रहती, लेकिन उस contract में intellectual property restrictions बहुत कड़ी थीं
      सारी open source गतिविधियाँ प्रतिबंधित थीं, जबकि उस समय हममें से कई लोग open source में बहुत सक्रिय थे। मैंने Eclipse Foundation में भी काम किया था
      एक दोस्त जो उपन्यास लिखता था, उससे कहा गया कि हर लेख पोस्ट या publish करने से पहले लिखित अनुमति चाहिए होगी
      German translation लगी होने के बावजूद contract की binding language English थी, और German engineers पर हस्ताक्षर करने का दबाव डाला गया; अंत में हममें से कई लोग बस नौकरी छोड़कर चले गए
      सबसे यादगार बात यह थी कि Canada से आई transition team ने कहा, “RIM employees अंधेरे concrete dungeon में काम करते हैं, इसलिए यह कितना सौभाग्य है कि तुम्हें Munich के शानदार office में काम जारी रखने दिया जा रहा है”
      उस कंपनी के DNA में खुला तरीका जैसी चीज़ पूरी तरह अजनबी लगती थी, और मैं उस पर ज़रा भी भरोसा नहीं करूँगा
    • एक विकल्प GPLv3 और commercial license का dual licensing है। GPLv3 में “3” महत्वपूर्ण है
      hobbyist developers और free/open source projects खुशी-खुशी GPLv3 operating system का उपयोग करेंगे, और पारंपरिक automotive/embedded बड़े commercial ग्राहक GPLv3 की उस बाध्यता से बचना चाहेंगे जिसमें users को custom firmware install करने देना पड़ता है, इसलिए वे भुगतान करते रहेंगे
      यह सभी के लिए फायदेमंद हो सकता है
      यह legal advice नहीं है, और license की व्याख्या हर किसी को खुद करनी चाहिए
    • RIM/Blackberry के organizational DNA में खराब developer experience गहराई से बसा हुआ है
      BB10 आने से पहले मैंने engineers से लंबी बात की थी, और मुझे याद है कि उस समय पूरे Blackberry SDK तक पहुँचने के लिए आवेदन करना पड़ता था और NDA पर हस्ताक्षर भी करने पड़ते थे
      दूसरी ओर Android और iOS तब तक तेज़ी से आगे बढ़ चुके थे, और वही platform सफल हुए जिन पर apps लिखना आसान था
      Blackberry community के साथ इस रिश्ते को संभालने में संगठनात्मक रूप से अक्षम दिखता है। carrier-शैली की “हम बनाम वे” सोच संगठन के ऊपरी स्तर पर है, और चाहे स्पष्ट रूप से हो या अप्रत्यक्ष रूप से, नीचे तक फैलती है
    • अगर 2004 से पहले की बात होती, तो QNX अब भी एक मायने रखने वाली स्थिति हासिल कर सकता था। वह वह दौर था जब users और developers operating systems के साथ प्रयोग करते थे, और desktop पर niche बनाने लायक लोगों को आकर्षित किया जा सकता था
      BeOS के विफल होने के बाद मैंने QNX के साथ प्रयोग और development किया, और मुझे यह इतना पसंद था कि मैं इसे अपने मुख्य development machine पर full-time इस्तेमाल करता था
      लेकिन जब यह बंद हुआ, तो मुझे बड़ा झटका लगा, और तब से मैंने किसी भी closed development platform को हाथ नहीं लगाया
      अब license देखकर लगता है कि कुछ भी नहीं बदला, और मौजूदा markets को छोड़ दें तो QNX अब ज़्यादातर अप्रासंगिक हो चुका है
      आज QNX चुनना मूर्खतापूर्ण लगता है। अब अच्छे alternatives मौजूद हैं, और सबके पास खुले license हैं
    • मैं यह भी जानना चाहता हूँ कि वास्तव में कितने applications को Linux से भी मजबूत real-time responsiveness की ज़रूरत होती है
      अब https://arstechnica.com/gadgets/2024/09/real-time-linux-is-o... भी है
      Linux इस्तेमाल करने पर license को लेकर बहस की ज़रूरत नहीं पड़ती, और अचानक धोखा खाकर source बंद हो जाने की चिंता भी नहीं रहती
      commercial use ban भयानक है। मैं अभी ArangoDB के साथ कुछ ऐसा ही झेल रहा हूँ; product अच्छा है, लेकिन उनके managed cloud instance का budget नहीं है और commercial license पर sales team से बात करने का भी budget नहीं है
      मैं इसे कई systems में इस्तेमाल कर रहा हूँ, और उनमें से एक database के उस 80% बिंदु तक पहुँच चुका है जहाँ वह “free में इस्तेमाल करने के लिए बहुत बड़ा” हो जाता है, लेकिन मुझे नहीं पता उसका भविष्य open source होगा, कोई product बनेगा, या सीधे revenue कमाने वाला system बनेगा
      इसलिए अभी का सबसे छोटा रास्ता उन लोगों से बात करना नहीं है जो शायद मेरे business model की अनुमति ही न दें, बल्कि PostgreSQL पर migrate करना है

  • QNX 8.0 के non-commercial उपयोग से जुड़े developer terms सीधे देखने के लिए यहाँ है: https://support7.qnx.com/download/download/51624/BB_QNX_Deve...
    यह कानूनी सलाह नहीं है, और न ही इस लाइसेंस की व्यापक समीक्षा या व्याख्या का सार है। नीचे दी गई बातों के आधार पर कुछ भी करने से पहले किसी वकील से पेशेवर सलाह लेनी चाहिए
    शर्तें ऐसे प्रावधान से शुरू होती हैं जिसमें लगता है कि उपयोगकर्ता को खुद, अपने व्यवसाय या अपनी संस्था को बाध्य करने से पहले इनकी समीक्षा और सहमति का अवसर नहीं मिला था; अमेरिका में इससे पूरा दस्तावेज़ अमान्य भी हो सकता है, इसलिए उपयोग से पहले वकील से इसकी समीक्षा कराना सुरक्षित है
    अकादमिक क्षेत्र में केवल उस संस्था के छात्र और faculty ही पात्र हैं, और इस लाइसेंस का उपयोग कानूनी टीम के नज़रिए से नियोक्ता की ओर से बाध्यकारी अनुबंध पर हस्ताक्षर करने जैसा माना जा सकता है
    यह सुनिश्चित करना चाहिए कि open source contributor होने के कारण आप पर कोई liability न आए, या संस्था की ओर से हस्ताक्षर करने का अधिकार होने का गलत दावा करने पर नौकरी जाने का जोखिम न हो
    cloud users के लिए शर्तों के अनुसार उपयोग AWS तक सीमित है; यदि इसे GCP, Heroku या किसी अन्य server instance पर इस्तेमाल किया गया जो आपके व्यक्तिगत contract control में नहीं है, तो लाइसेंस शुल्क देना पड़ सकता है
    यहाँ अनुमति प्राप्त “Open Source” केवल OSI परिभाषा तक सीमित है, इसलिए जो लोग restrictive non-commercial license के तहत software वितरित करते हैं, वे QNX non-commercial license का उपयोग नहीं कर सकते
    “high-risk” क्लॉज़ उन applications के विकास पर रोक लगाता है जो समाज को नुकसान पहुँचा सकते हैं, इसलिए social apps भी इससे बाहर हो सकते हैं। कोई viral application बनाते समय इस क्लॉज़ का उल्लंघन न हो, इसका ध्यान रखना चाहिए
    इस product के संबंध में इस्तेमाल किए जाने वाले सभी hardware के पहचाने जा सकने वाले सभी serial numbers एकत्र और संग्रहीत किए जाते हैं
    non-commercial license को, चाहे शर्तों का ईमानदारी से पालन किया गया हो, कभी भी बिना किसी शर्त के समाप्त किया जा सकता है, और उस समय आपको अज्ञात लागत पर ऐसा अपरिभाषित “certification” देना पड़ सकता है कि आपको दिया गया सारा QNX code आपने हटा दिया है

    • समझ नहीं आता social app कब से high-risk हो गया। high-risk clause साफ़ तौर पर IEC 61508, ISO 26262 जैसी safety requirements वाले applications के लिए है
      Twitter client बंद हो जाने से किसी को चोट नहीं लगेगी या कोई मरेगा नहीं

  • जब real-time Linux इतना mature हो चुका है, तो किसी project में QNX इस्तेमाल करने की वजह है भी क्या? क्या फिर से किसी अचानक license change से झटका खाने की चिंता करनी चाहिए?
    अगर वजह सिर्फ यह है कि यह प्यारा है और अकादमिक रूप से दिलचस्प है, तो मैंने पहले QNX इस्तेमाल किया है
    लेकिन अगली बार जब किसी project के लिए SoC और उसके साथ आने वाला BSP चुनूँगा, तो QNX नहीं ढूँढूँगा। शायद bundled FreeRTOS distribution इस्तेमाल करूँगा या Android build tools इंस्टॉल करके किसी अजीब Android fork में APK push कर दूँगा
    automotive या medical क्षेत्र में बात अलग हो सकती है, लेकिन वहाँ भी competitors लगातार पीछे लगे हैं, और Linux real-time changes से स्थिति और कठिन होगी
    अभी 2010 नहीं है। विकल्प बहुत हैं, और जब तक QNX अस्पष्ट और परेशान करने वाली licensing requirements के पीछे अटका रहा, दर्जनों कंपनियाँ alternatives बनाती रहीं। उनमें से कुछ काफ़ी बड़ी हैं, और कुछ तो space तक जा चुकी हैं
    अब QNX को गंभीरता से लिया जाना है तो सिर्फ “पहले की तरह QNX का दरवाज़ा खोलना शुरू करना” काफ़ी नहीं होगा
    commercial use तक के लिए पूरी तरह open source न हो, तो मुझे इसमें कोई दिलचस्पी नहीं। अगर tools और BSP support मेरे समय की कीमत वसूल कर दें, तो Epic-style license शायद स्वीकार कर लूँ, लेकिन सिर्फ शुरुआत करने के लिए license fee देने में बिल्कुल रुचि नहीं है
    product अब commoditized हो चुका है और अब बस जिज्ञासा की चीज़ है। पर्याप्त सक्रिय development और adoption पाने का एकमात्र तरीका है कि यह community project बने

    • नाम और reputation अब भी कुछ लोगों के लिए बहुत मायने रखते हैं, और यह भी महत्वपूर्ण है कि उन्हें कोई दूसरा operating system सीखना नहीं पड़े
      हर कोई free/open source होने की परवाह नहीं करता, और ऐसे मुद्दों पर लोगों का अलग-अलग दिशा में झुकना कोई हैरानी की बात नहीं
    • अगर आप real-time operating system development की नौकरी पाना चाहते हैं और दिखाना चाहते हैं कि आप इस क्षेत्र को गंभीरता से लेते हैं, तो इसका उपयोग कर सकते हैं

  • 2000 के दशक की शुरुआत में जिन operating systems को मैंने इस्तेमाल किया, उनमें पुराने single-core 90s के मध्य के Pentium को शानदार और फुर्तीला महसूस कराने वाले सिर्फ़ QNX और BeOS थे
    वे किसी भी Windows version या Linux से कहीं बेहतर थे
    मेरा मानना है कि दोनों ही मामलों में इसकी वजह मुख्य रूप से scheduler और कहीं बेहतर multimedia stack थी
    मैं हमेशा उम्मीद करता था कि भविष्य के operating systems में वही एहसास होगा, और उसके सबसे क़रीब शायद iOS है, हालांकि वह भी processes को बार-बार मारने जैसी जुगत लगाता है। भविष्य कुछ ख़ास नहीं निकला

    • BeOS “कुल मिलाकर” multithreaded था, और marketing भाषा हटाकर कहें तो इसका मतलब यह था कि kernel में एक विशाल single lock नहीं था। क्योंकि इसे शुरू से multi-core systems के लिए डिज़ाइन किया गया था
      उस समय के समकालीन operating systems में ऐसे विशाल single lock हुआ करते थे
      BeOS का preemption interval 750ms था या 3ms, यह याद नहीं, लेकिन Linux और Windows के 20ms, बाद में 10ms, से छोटा था, इसलिए शायद वही अंतर महसूस हुआ होगा
      दशकों बाद ज़्यादातर operating systems ने kernel space में finer-grained locking का स्तर पकड़ लिया, लेकिन preemption interval अभी भी throughput बनाम latency बहस की वजह से अलग-अलग है। क्योंकि script-based operating system benchmarks कुल throughput मापते हैं, GUI responsiveness नहीं
      media buffer इसका अच्छा उदाहरण है, जिन्हें छोटे buffer size से फ़ायदा मिलता है, और throughput घटने पर भी musicians ने BeOS की बेहतर responsiveness को महसूस किया, इसलिए उसे “Media OS” जैसा उपनाम मिला
      GUI space में भी BeOS/Haiku app server दूसरे desktop environments की तुलना में वितरित workload देता है। हर window को अपनी thread मिलती है, app को भी अपनी thread मिलती है, और app तथा application server, app और window के हिसाब से एक-एक thread रखते हैं ताकि धीमे app message parsing का इंतज़ार करते हुए वे block न हों
      इसलिए graphical “Hello World” window वाले न्यूनतम BeOS app में भी 4 threads होती हैं। app व्यस्त हो तब भी बाक़ी system responsive महसूस होता है
      बदले में throughput की क़ीमत और app development की complexity की क़ीमत चुकानी पड़ती है, ख़ासकर ported apps में
      Haiku को multithread bugs से बचाने के लिए Qt/Gtk/toolkit messages को कई windows से एक single message queue में serialize करना पड़ता है। क्योंकि मूल environment में app message loop multithreaded नहीं था
      इस serialization की वजह से जब इसकी ज़रूरत नहीं भी हो, जैसे उसी window में जाने वाले messages के लिए, Haiku में अतिरिक्त lock/unlock calls करनी पड़ती हैं
      दूसरी ओर Haiku native apps बर्फ़ जैसी स्मूथ चलती हैं। यहाँ Medo video editor का screenshot है, जिसमें हर window अपनी thread पर चलती है: https://raw.githubusercontent.com/smallstepforman/Medo/refs/...
      आधुनिक systems पर यह app बर्फ़ जैसी स्मूथ है, जो एक video editor के लिए लगभग विधर्म जैसा है। लिंक किया गया Haiku app मैंने लिखा है
    • मैं सचमुच उस दिन का सपना देखता हूँ जब आधुनिक computers पुराने Commodore 128 की तरह जल्दी boot हों, जल्दी reset हों, और हर key input पर responsive रहें
    • जुगत लगाता है, लेकिन कम से कम कोशिश तो करता है, इसका श्रेय देना होगा
      जब Samsung तक ने phone responsiveness को गंभीरता से सुधारने की कोशिश नहीं की थी, तब मैंने Android छोड़ दिया था
      यह अच्छी बात है कि Apple लगातार responsiveness को महत्व देता है, और इसी वजह से Google, Samsung, Microsoft को भी अपने फूले हुए products को दुरुस्त करने की प्रेरणा मिलती है
    • BeOS और OS/2 Warp इस्तेमाल कर चुके व्यक्ति के तौर पर, मुझे पुराने systems की फुर्ती याद आती है। QNX को मैंने खुद नहीं चलाया
      आज के operating systems में उस फुर्ती के सबसे क़रीब क्या है? क्या Haiku OS है?
      मैं M1 MacBook अच्छे से इस्तेमाल कर रहा हूँ, लेकिन कभी-कभी वह भी काफ़ी नहीं लगता
    • QNX तो मैंने नहीं चलाया, लेकिन BeOS पर Pentium 90 का बहुत शानदार महसूस होना मेरा भी मिलता-जुलता अनुभव है
      एक और उदाहरण SGI IRIX था, जिसका scheduler असाधारण रूप से अच्छा था। मैंने कुछ समय 30MHz machine इस्तेमाल की थी और desktop काफ़ी फुर्तीला था
      एक दिन मैंने AMP compile किया और MP3 की एक list चलाई, जिनमें ज़्यादातर 192kbps थीं; संदर्भ के लिए, यह program 256kbps भी बिना अटके decode कर सकता था
      files NFS share पर थीं, और जब gr_osview चलाया तो CPU usage 95% था, फिर भी file manager responsive था और music नहीं अटक रहा था
      30MHz पर 192kbps से ऊपर की high-bitrate MP3 decode कर लेना ही अपने आप में प्रभावशाली था
      पूरे X Window System desktop को चलाते हुए, NFS share से files play करते हुए भी responsiveness बनी रही, यह दिखाता है कि network stack और scheduler हल्के लेकिन मज़बूत थे और कमज़ोर hardware पर भी अच्छे से काम करते थे
      वह IRIX 5.3, Indigo Elan था
      मेरे एक दोस्त और मुझे operating systems पसंद थे, इसलिए हमने पुराने Pentium 90 पर BeOS चलाया था, और जैसा ऊपर कहा, वह फुर्तीला था
      Linux ने भी अपना योगदान दिया। पानी से नुकसान होने के बाद वह Pentium 90 स्थिर नहीं रहा था, और parity के बिना RAM इस्तेमाल करने की वजह से Windows NT धीरे-धीरे गड़बड़ होने लगता था और बार-बार blue screen देता था
      मज़े के लिए हमने Red Hat 5.2 डाला, और वह अच्छी तरह चला। system log में हर सेकंड बहुत सी entries आती थीं, और X console खोलकर उन्हें बस स्क्रॉल होते देख सकते थे
      उस machine ने मज़े-मज़े में कुछ हफ़्तों तक हमारी company web page भी serve की थी। अच्छे दिन थे

  • एक विवरण और जोड़ूँ तो, QNX source code 2007 से 2010 में RIM/Blackberry के अधिग्रहण से पहले तक उपलब्ध था
    क्या आगे चलकर QNX source code access फिर से देने की कोई योजना है?
    https://www.qnx.com/news/pr_2471_1.html

    • वे कहते हैं कि timeline पर पक्का वादा न किया जाए, लेकिन यह साफ़ है कि चीज़ें ज़्यादा open और transparent दिशा में जा रही हैं
      हम सुन रहे हैं कि यह customers और community दोनों के लिए महत्वपूर्ण है। देखते रहिए

  • पिछली कंपनी मोबाइल नेटवर्क के लिए high-availability Active/Standby router बनाती थी, और operating system के रूप में QNX इस्तेमाल करती थी। उसकी क्षमताएँ आज भी प्रभावशाली लगती हैं
    याद थोड़ी धुंधली है, लेकिन control plane processor पर QNX चलता था, और router के internal network के ज़रिए remote processor पर process शुरू करने का native support था
    यानी low-level inter-process communication में IP का इस्तेमाल हो सकता था, और QNX का IPC high-availability failover features के लिए ज़रूरी था
    यह भी शानदार था कि device driver user-space process होते थे, इसलिए crash होने पर उन्हें restart किया जा सकता था। मैं network driver develop कर रहा था, इसलिए ऐसा कभी-कभी सचमुच होता था
    Linux में जहाँ network device अपवाद की तरह /dev/ tree में ठीक से दिखाई नहीं देते, उसके विपरीत devices का वास्तव में /dev/ tree में दिखना भी बेहतर था
    एक मज़ेदार किस्सा यह है कि एक बार IPC return value पर गलती से const लगा देने की वजह से समस्या हो गई, और मेरा process QNX के IPC function और मेरे function के बीच में मर गया
    मैंने कई दिन debugging की, और उस समय के C/user-space debugger के स्तर पर उस error को पकड़ना संभव नहीं था

    • मैंने भी मोबाइल नेटवर्क के लिए router संभाले हैं, और सब कुछ Linux पर चलता था, control plane भी Linux पर ही था
      line cards भी Linux पर थे, लेकिन वे सिर्फ control plane के निर्देशानुसार ASIC को program करने का काम करते थे
      ऐसी features खास तौर पर संबंधित नहीं हैं, और IPC आप HTTP से करें या किसी भी मनचाहे तरीके से कर सकते हैं
    • internal network के ज़रिए remote processor पर process शुरू करना CP/NET(https://en.wikipedia.org/wiki/MP/M#CP/NET) या JUNET के साथ CP/J([https://pl.wikipedia.org/wiki/JUNET_(CP/J)) में भी पहले से संभव था

  • @JohnAtQNX क्या website download पर सबके लिए account-required restriction हटाई जा सकती है, और qcc का license mechanism भी हटाया जा सकता है?
    इससे hobby developers को इसे आज़माने के लिए प्रोत्साहन मिलेगा
    आमदनी शायद bulk licensing deals से आती होगी, और संरचना per-device license fee वाली होगी
    अगर आप QNX product line को support करने वाली CI/CD teams को नाराज़ करते हैं, तो वही revenue source खतरे में पड़ सकता है

    • इसे कैसे संभव बनाया जा सकता है, इस पर अंदरूनी चर्चा हुई थी
      बाहर से भी वही बात सुनना अच्छा है, मैं इसे फिर से मेज़ पर लाकर थोड़ा-थोड़ा आगे बढ़ाने की कोशिश करूँगा
    • कम-से-कम Google जैसी दूसरी services से login करने की सुविधा तो होनी ही चाहिए। बहुत सी sites पहले से ऐसा कर रही हैं
      हर बार कुछ नया आने पर एक और नया login जोड़ना मुझे सच में पसंद नहीं
      news feeds में भी यही हाल है; लगभग आधी news sites “free” कहकर भी login माँगती हैं। उस स्थिति में इतना अच्छा है कि वही article कहीं और आसानी से मिल जाता है
    • सही बात है। लोग friction कम होने वाली दूसरी जगह पर जाने की अधिक संभावना रखते हैं

  • मुझे अभी भी वह single-floppy QNX demo याद है जिसमें web browser तक शामिल था। वह सचमुच बहुत तेज़ था
    आशा है यह सफल हो। किसी चीज़ को वास्तव में खोलने के लिए सारे legal मसलों को सुलझाना कितना कठिन Gordian knot होगा, इसका बस अंदाज़ा ही लगाया जा सकता है
    जैसा और लोगों ने कहा, दो बार धोखा खा चुके होने के कारण सब सतर्क हैं, लेकिन QNX में आनंद लेने लायक बहुत कुछ है, इसलिए उम्मीद है इस बार इसे momentum मिले

    • 90 के दशक के उत्तरार्ध में वह QNX demo floppy जादू जैसा था। उसने दिखाया था कि उस समय Linux/Windows की तुलना में 486 DX2 या DX4 CPU पर चीज़ें कितनी तेज़ महसूस हो सकती थीं
      उसके बाद से QNX के बारे में मेरे मन में कुछ हद तक सकारात्मक धारणा रही, लेकिन बीच के ownership changes और public/commercial status changes की वजह से मैं हमेशा इससे दूर ही रहा
      दुर्भाग्य से यह मौजूदा “opening” भी जानी-पहचानी लगती है, और मेरा मानना है कि जब तक सचमुच open GPL license और fork को बनाए रखने लायक बड़ा free/open-source community नहीं बनता, इसे फिर वापस ले लिया जाएगा

  • यह एक अच्छा साहसी प्रयास है। मैं लंबे समय से QNX को दिलचस्पी से देखता आया हूँ, लेकिन ज्यादातर मामलों में संभावित user नहीं रहा
    अगला अच्छा कदम यह होगा कि आम hobby project types में से कुछ चुने जाएँ और blog post series में समझाया जाए कि उन स्थितियों में QNX की ताकतों को कैसे लागू किया जा सकता है

    • मैं भी ऐसे लेख देखना चाहूँगा। मुझे QNX में दिलचस्पी है, लेकिन घर पर robots के साथ काम करने वाले व्यक्ति के रूप में मुझे साफ नहीं है कि इससे मुझे क्या लाभ होगा
      मैं एक non-profit में भी काम करता हूँ जो coastal boundary research करता है, और वहाँ कुछ लोग custom hardware बनाते हैं। क्या यह हमारे लिए भी उपयोगी हो सकता है?

  • हम Rizin में free/open-source reverse engineering और debugging framework के लिए QNX support बेहतर करना चाहते हैं
    support पहले से है[1][2][3][4], लेकिन हम इसे स्थिर रूप से test नहीं कर सकते
    जैसे Windows test के लिए time-limited VM सीधे उपलब्ध कराता है[5], वैसे ही अगर QEMU image भी डिफ़ॉल्ट रूप से उपलब्ध हो तो अच्छा होगा
    [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...

    • मुफ्त QNX Everywhere license के साथ संभवतः IDE में कुछ clicks करके QEMU VM चलाया जा सकता है
      फिर भी, मैं समझता हूँ कि Windows image की तरह one-click download और आसान होगा, और मैं यह feedback आगे पहुँचाऊँगा
      अगर QNX support संभव बनाने में मैं किसी और तरीके से मदद कर सकता हूँ, तो DM करें या qnxcommunityengagement at qnx dot com पर संदेश भेजें