QNX เปิดให้ใช้ฟรีสำหรับการใช้งานที่ไม่ใช่เชิงพาณิชย์ และเพิ่มอิมเมจสำหรับ Raspberry Pi

 (blackberry.qnx.com)
1 คะแนน โดย GN⁺ 2024-11-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักพัฒนา OS แบบฝังตัวและเรียลไทม์สามารถทดลองใช้ QNX SDP 8.0 ได้ฟรีสำหรับการศึกษา งานอดิเรก และการทำต้นแบบ ทำให้กำแพงการเข้าถึงที่เดิมเน้นเชิงพาณิชย์ลดลง
  • ผู้ใช้ต้องส่งแบบฟอร์มไลเซนส์ด้วย บัญชี myQNX และหลังจากคำขอได้รับการประมวลผลแล้ว จะได้รับไลเซนส์ซอฟต์แวร์ QNX สำหรับการใช้งานที่ไม่ใช่เชิงพาณิชย์
  • ขอบเขตที่ให้ใช้งานครอบคลุม QNX SDP 8.0, QNX Developer Desktop และ QNX Hypervisor ทำให้ต่อยอดได้ตั้งแต่การเรียนรู้ OS ไปจนถึงการพัฒนาแบบ self-hosted และการทดลองด้าน virtualization
  • มีทรัพยากรสำหรับเริ่มต้นให้ ได้แก่ Quick Start Guide, อิมเมจ QNX 8.0 สำหรับ Raspberry Pi, วิดีโอ QNX Everywhere และ Self-Hosted Developer Desktop Guide
  • ไลเซนส์ฟรีจำกัดเฉพาะการศึกษา โปรเจกต์ส่วนตัว และการเรียนรู้ RTOS ส่วน การประเมินหรือพัฒนาเพื่อวัตถุประสงค์เชิงพาณิชย์ ต้องขอไลเซนส์ทดลองใช้ 30 วันแยกต่างหาก

การให้สภาพแวดล้อมพัฒนา QNX สำหรับการใช้งานที่ไม่ใช่เชิงพาณิชย์

  • QNX Everywhere เป็นโปรแกรมที่เปิดให้นักศึกษา นักพัฒนาสายงานอดิเรก และผู้ทำต้นแบบใช้ซอฟต์แวร์ QNX ได้ฟรีเพื่อวัตถุประสงค์ที่ไม่ใช่เชิงพาณิชย์
  • สิ่งที่ให้ใช้งานครอบคลุม OS รุ่นถัดไปของ QNX, เครื่องมือพัฒนา และความสามารถแบบเรียลไทม์ ซึ่งสามารถนำไปใช้ในการเรียนรู้ ทดลอง และสร้างโปรเจกต์ embedded ประสิทธิภาพสูงได้
  • ตัวเลขที่เปิดเผยมีการดาวน์โหลดไลเซนส์ QNX Everywhere 15K+, ผู้เรียนออนไลน์ที่ลงทะเบียน 6K+ และสถาบันการศึกษาพันธมิตร 100+ แห่ง

ขั้นตอนการขอไลเซนส์

  • หากต้องการรับไลเซนส์สำหรับการใช้งานที่ไม่ใช่เชิงพาณิชย์ จำเป็นต้องมี บัญชี myQNX
    • หากมีบัญชีอยู่แล้ว ให้เข้าสู่ระบบ
    • หากใช้ QNX เป็นครั้งแรก ให้สร้างบัญชี myQNX
  • หลังเข้าสู่ระบบ ให้กรอกข้อมูลไลเซนส์ใน แบบฟอร์มไลเซนส์ QNX Everywhere เพื่อเริ่มคำขอ
  • เมื่อการประมวลผลคำขอเสร็จสมบูรณ์ จะได้รับไลเซนส์ซอฟต์แวร์ QNX สำหรับการใช้งานที่ไม่ใช่เชิงพาณิชย์
  • หลังส่งคำขอแล้ว ไลเซนส์อาจใช้เวลาสูงสุด 1 ชั่วโมง จึงจะแสดงในโปรไฟล์ myQNX

แพลตฟอร์มและเครื่องมือที่รวมอยู่

  • QNX SDP 8.0 เป็นแพลตฟอร์มพัฒนาพื้นฐานสำหรับ SoC รุ่นถัดไป
    • รวม QNX Operating System รุ่นถัดไปไว้ด้วย
    • ชูสถาปัตยกรรมที่ออกแบบมาเพื่อใช้ประโยชน์จากความก้าวหน้าของซิลิคอนในอนาคต
    • มีเป้าหมายเพื่อมอบประสิทธิภาพแบบเรียลไทม์ที่สม่ำเสมอในระบบที่ต้องใช้การประมวลผลสูงทั่วทั้ง IoT
    • รวม toolchain ที่อัปเกรดแล้ว, ยูทิลิตีใหม่สำหรับ debugging และ profiling และยูทิลิตีโอเพนซอร์ส
  • QNX Everywhere รวมสิทธิ์เข้าถึงรายการต่อไปนี้
    • QNX SDP 8.0: แพลตฟอร์ม microkernel RTOS ประสิทธิภาพสูงที่พร้อมสำหรับงานด้านความปลอดภัย
    • QNX Developer Desktop: เดสก์ท็อปแบบ self-hosted สำหรับสร้างแอปพลิเคชันบน QNX OS 8.0
    • QNX Hypervisor: hypervisor แบบ deterministic สำหรับระบบที่มีระดับความสำคัญแบบผสม

การศึกษา คอมมูนิตี้ และโอเพนซอร์ส

  • QNX มี หลักสูตรออนไลน์ฟรี สำหรับนักพัฒนา QNX OS
  • นักพัฒนาสามารถเชื่อมต่อกับวิศวกร QNX และคอมมูนิตี้นักพัฒนาออนไลน์ เพื่อแก้ปัญหา พูดคุยไอเดีย และร่วมงานกันในโปรเจกต์โอเพนซอร์สได้
  • เนื่องจากเป็น OS ที่รองรับ POSIX จึงสามารถคอมไพล์ซอฟต์แวร์จำนวนมากสำหรับระบบปฏิบัติการ POSIX ให้ใช้งานบน QNX ได้โดยแทบไม่ต้องแก้ไข
  • QNX เผยแพร่ซอร์สโค้ดของพอร์ตโอเพนซอร์สตามไลเซนส์เดิม และดูแลพอร์ตที่นักพัฒนาสามารถนำไปใช้ได้ใน GitHub repository
  • สามารถตรวจสอบพอร์ต ระดับการทดสอบ และรายละเอียดการโฮสต์ได้ที่ Open-Source Dashboard

เริ่มต้นด้วยเอกสารและอิมเมจ Raspberry Pi

  • เอกสาร QNX Everywhere ให้เครื่องมือและคำแนะนำที่จำเป็นสำหรับการสร้างตั้งแต่แอปพลิเคชันแรกไปจนถึงโซลูชัน QNX ขั้นสูง
  • ทรัพยากรที่มีให้มีดังนี้
  • ผู้ใช้ Raspberry Pi 5 สามารถแฟลชและใช้งาน อิมเมจ QNX SDP 8.0 ที่เตรียมไว้ได้
    • อิมเมจมีแอปพลิเคชันเดโมโอเพนซอร์สหลายรายการรวมอยู่ด้วย
    • แอปพลิเคชันเดโมสามารถ clone, แก้ไข และ rebuild ได้

เงื่อนไขการใช้งานและสิ่งที่ไม่ครอบคลุม

  • ไลเซนส์ฟรีมีไว้สำหรับผู้ใช้ส่วนบุคคลที่ใช้งาน QNX Software Development Platform 8.0 แบบไม่ใช่เชิงพาณิชย์
  • การใช้งานที่อนุญาตคือเพื่อการศึกษา โปรเจกต์ส่วนตัว และกิจกรรมที่ไม่มีการสร้างรายได้หรือดำเนินธุรกิจ
  • การใช้งานที่ไม่ใช่เชิงพาณิชย์รวมถึงสภาพแวดล้อมทางวิชาการ นักพัฒนาสายงานอดิเรก และผู้เรียนรู้ระบบปฏิบัติการเรียลไทม์
  • ไม่รวมการประเมินหรือการพัฒนาเพื่อวัตถุประสงค์เชิงพาณิชย์
    • กิจกรรมเชิงพาณิชย์รวมถึงการสร้างรายได้หรือการดำเนินธุรกิจ
    • ไลเซนส์ทดลองใช้ 30 วัน สำหรับเชิงพาณิชย์ต้องยื่นขอแยกต่างหาก
  • QNX SDP 7.1 ไม่รวมอยู่ในโปรแกรมนี้
    • QNX SDP 8.0 จัดให้สอดคล้องกับแพลตฟอร์มซอฟต์แวร์รุ่นถัดไปที่ใช้ SoC ซึ่งมีคอร์ CPU 4 คอร์ขึ้นไป

การติดตั้งหลายเครื่องสำหรับสถาบันการศึกษา

  • หากต้องการตั้งค่าเวิร์กสเตชันหลายเครื่องในห้องแล็บหรือห้องเรียน สามารถรับไลเซนส์แบบผู้ใช้หลายคนผ่านโปรแกรม QNX in Education ได้
    • กลุ่มเป้าหมายรวมถึง QNX Software Development Platform 8.0 และ QNX Software Development Platform 7.1
  • หากติดตั้งเพียงหนึ่ง instance ต่อครั้ง แนะนำให้ใช้ไลเซนส์ QNX Everywhere

การแก้ปัญหาบัญชีและไลเซนส์

  • หากมีปัญหาในการเข้าสู่ระบบหลังลงทะเบียนบัญชี myQNX ใหม่ ให้ติดต่อ myqnx@blackberry.com
  • สามารถตรวจสอบและยอมรับสถานะไลเซนส์และการแจกจ่ายผลิตภัณฑ์ได้ใน myQNX License Manager
  • ในส่วน Registered Products ของโปรไฟล์บัญชี myQNX จะแสดง license key, serial number, license certificate และ license manager สำหรับแต่ละผลิตภัณฑ์ที่แจกจ่าย
  • หากต้องการดาวน์โหลด QNX Software Center ผู้ใช้ myQNX ต้องได้รับการกำหนดไลเซนส์ผลิตภัณฑ์ QNX แล้ว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-11-08
ความคิดเห็นจาก Hacker News

  • ถ้าเชื่อได้ก็คงดี แต่ QNX เคย “เปิด” แล้วกลับไปปิดอีกถึงสองครั้ง มาก่อน
    ก่อนการถอนกลับครั้งแรก โปรเจกต์โอเพนซอร์สมักใส่ QNX เป็นเป้าหมายการบิลด์อยู่บ่อย ๆ และยังมีการรองรับเป้าหมายสำหรับ Firefox และ Eclipse บน QNX รวมถึงสามารถบิลด์ GCC และเครื่องมือบรรทัดคำสั่งของ GNU ได้ด้วย
    ตอนนั้นยังมีสภาพแวดล้อมเดสก์ท็อปชื่อ Photon และผมใช้มันเป็นเดสก์ท็อปหลักอยู่ 3 ปีตอนสร้างรถสำหรับ DARPA Grand Challenge
    แต่หลังจาก Harman เข้าซื้อ QNX ในปี 2004 ทุกอย่างก็หายไป และในปี 2007 ก็เปิดซอร์สอีกครั้ง จนสามารถดูและบิลด์ไปถึงระดับไมโครเคอร์เนลได้ แต่ก็ไม่ใช่ไลเซนส์สาธารณะ
    พอ RIM เข้าซื้อ QNX ในปี 2010 ก็ปิดซอร์สโดยไม่มีการแจ้งล่วงหน้า การพัฒนาโอเพนซอร์สที่เกี่ยวกับ QNX ทั้งหมดหยุดชะงัก และความเชื่อมั่นจากชุมชนก็หายไปด้วย
    เงื่อนไขสัญญาก็เป็นปัญหาเช่นกัน: 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 คือดาวน์โหลดซอร์สมาใช้ได้เต็มที่ ฟรีจนกว่ารายได้จากผลิตภัณฑ์จะถึง 1 ล้านดอลลาร์ หลังจากนั้น Epic เก็บค่ารอยัลตี้ 5%: https://cdn2.unrealengine.com/UnrealEngine/faq/UnrealEngineE...
    ปัญหาการละเมิดลิขสิทธิ์ก็ไม่ได้ใหญ่นัก เพราะถ้าเกมทำรายได้อย่างมีนัยสำคัญ มันก็จะโดดเด่นพอให้ฝ่ายไลเซนส์รู้ได้
    ถ้าอยากเพิ่มการใช้งาน QNX ก็ควรเอาตารางเงื่อนไขของ Epic ไปให้ฝ่ายกฎหมายกับผู้บริหารดู แล้วเทียบการเติบโตของรายได้ Unreal Engine กับ QNX
    อย่างที่เคยบอกพนักงานขายของ QNX ไป ปัญหาของ QNX ไม่ใช่การละเมิดลิขสิทธิ์ แต่คือ การถูกเมิน

    • ในปี 2011 ผมทำงานที่สตาร์ทอัพเยอรมันแห่งหนึ่งซึ่งถูก RIM/Blackberry เข้าซื้อ บริษัทพยายามให้พนักงานทุกคนเซ็นสัญญาใหม่ที่คงบทบาทและเงินเดือนเดิมไว้ แต่สัญญานั้นมี ข้อจำกัดด้านทรัพย์สินทางปัญญา รุนแรงมาก
      กิจกรรมโอเพนซอร์สทั้งหมดถูกห้าม และตอนนั้นพวกเราหลายคนมีส่วนร่วมกับโอเพนซอร์สอย่างแข็งขัน ผมเองก็เคยทำงานที่ Eclipse Foundation ด้วย
      เพื่อนคนหนึ่งที่เขียนนิยายได้รับแจ้งว่าทุกครั้งที่เขาโพสต์หรือเผยแพร่งานเขียน ต้องได้รับอนุญาตเป็นลายลักษณ์อักษรก่อน
      แม้จะมีฉบับแปลภาษาเยอรมันแนบมาด้วย แต่พวกเขาก็บังคับให้วิศวกรเยอรมันเซ็นสัญญาที่ระบุว่าภาษาที่มีผลผูกพันคือภาษาอังกฤษ สุดท้ายพวกเราหลายคนก็ลาออกไป
      สิ่งที่จำได้ชัดที่สุดคือทีมเปลี่ยนผ่านจากแคนาดาบอกว่า “พนักงาน RIM ทำงานในคุกใต้ดินคอนกรีตมืด ๆ ดังนั้นพวกคุณโชคดีแค่ไหนที่ยังได้ใช้ออฟฟิศสวย ๆ ในมิวนิกต่อไป”
      ใน DNA ของบริษัทนั้น แนวทางแบบ เปิด ดูเป็นสิ่งที่แปลกแยกโดยสิ้นเชิง และผมจะไม่เชื่อเลยแม้แต่น้อย
    • ทางเลือกหนึ่งคือ dual license ระหว่าง GPLv3 กับไลเซนส์เชิงพาณิชย์ โดยเลข “3” ใน GPLv3 สำคัญมาก
      นักพัฒนางานอดิเรกและโปรเจกต์เสรี/โอเพนซอร์สน่าจะยินดีใช้ระบบปฏิบัติการ GPLv3 ส่วนลูกค้าเชิงพาณิชย์รายใหญ่แบบดั้งเดิมในสายยานยนต์/embedded คงไม่ต้องการภาระผูกพันของ GPLv3 ที่ต้องเปิดให้ผู้ใช้ติดตั้งเฟิร์มแวร์ปรับแต่งเองได้ จึงยังคงจ่ายเงินต่อไป
      อาจเป็นประโยชน์กับทุกฝ่ายได้
      นี่ไม่ใช่คำแนะนำทางกฎหมาย และการตีความไลเซนส์ต้องพิจารณากันเอง
    • ใน DNA องค์กรของ RIM/Blackberry ฝัง ประสบการณ์นักพัฒนาที่แย่ เอาไว้
      ผมเคยคุยยาว ๆ กับวิศวกรก่อน BB10 ออกมา จำได้ว่าตอนนั้นถ้าจะเข้าถึง Blackberry SDK ทั้งชุดต้องยื่นคำขอ และต้องเซ็น NDA ด้วย
      ขณะเดียวกัน Android กับ iOS กำลังไปได้แรงแล้ว และฝ่ายที่ให้ความสำคัญกับแพลตฟอร์มที่เขียนแอปได้ง่ายเป็นอันดับแรกก็เป็นฝ่ายชนะ
      Blackberry ดูเหมือนไร้ความสามารถในเชิงองค์กรในการจัดการความสัมพันธ์แบบนี้กับชุมชน วิธีคิดแบบผู้ให้บริการโทรคมนาคมที่ว่า “เรา vs พวกเขา” อยู่ในระดับบนขององค์กร และซึมลงมาข้างล่างไม่ว่าจะโดยชัดแจ้งหรือโดยนัย
    • ถ้าเป็นช่วงก่อนปี 2004 QNX ยังอาจยึดตำแหน่งที่มีความหมายได้ ตอนนั้นเป็นยุคที่ผู้ใช้และนักพัฒนาทดลองระบบปฏิบัติการกัน และสามารถดึงคนเข้ามาได้พอจะสร้าง niche บนเดสก์ท็อป
      หลัง BeOS ล้มเหลว ผมเล่นและพัฒนาบน QNX และชอบมันมากพอจะใช้เต็มเวลาเป็นเครื่องพัฒนาหลัก
      แต่พอมันถูกปิด ผมก็เข็ดหนัก และหลังจากนั้นก็ไม่แตะ แพลตฟอร์มพัฒนาแบบปิด อีกเลย
      พอมาดูไลเซนส์ตอนนี้ ก็ไม่เห็นว่ามีอะไรเปลี่ยนไปแม้แต่น้อย และตอนนี้นอกจากตลาดเดิม ๆ แล้ว QNX ก็แทบไม่เกี่ยวข้องเท่าไร
      การเลือก QNX วันนี้ดูเป็นเรื่องโง่ ตอนนี้มีทางเลือกดี ๆ แล้ว และทั้งหมดมีไลเซนส์แบบเปิด
    • ผมก็สงสัยเหมือนกันว่าแอปพลิเคชันที่ต้องการ การตอบสนองแบบเรียลไทม์ที่แข็งกว่า Linux จริง ๆ มีมากแค่ไหน
      ตอนนี้ยังมี https://arstechnica.com/gadgets/2024/09/real-time-linux-is-o... แล้วด้วย
      ถ้าใช้ Linux ก็ไม่ต้องถกเรื่องไลเซนส์ และไม่ต้องกลัวว่าจะถูกหักหลังแล้วปิดแบบกะทันหัน
      การห้ามใช้งานเชิงพาณิชย์นั้นแย่มาก ตอนนี้ผมกำลังเจอเรื่องคล้ายกันกับ ArangoDB ผลิตภัณฑ์ดีนะ แต่ผมไม่มีงบสำหรับคลาวด์อินสแตนซ์ที่พวกเขาจัดการ และไม่มีงบไปคุยเรื่องไลเซนส์เชิงพาณิชย์กับฝ่ายขาย
      ผมใช้มันอยู่ในหลายระบบ และหนึ่งในนั้นมาได้ถึงราว 80% ของฐานข้อมูลที่ “ใหญ่เกินกว่าจะใช้ฟรี” แล้ว แต่ก็ยังไม่รู้ว่าชะตาของมันจะเป็นโอเพนซอร์ส เป็นผลิตภัณฑ์ หรือเป็นระบบที่ทำเงินโดยตรงหรือไม่
      ดังนั้นเส้นทางสั้น ๆ ตอนนี้จึงไม่ใช่การไปคุยกับคนที่อาจไม่ยอมรับโมเดลธุรกิจของผม แต่คือการย้ายไป PostgreSQL

  • หากต้องการดูเงื่อนไขสำหรับนักพัฒนาที่เชื่อมโยงกับการใช้งาน QNX 8.0 แบบไม่ใช่เชิงพาณิชย์โดยตรง อยู่ที่นี่: https://support7.qnx.com/download/download/51624/BB_QNX_Deve...
    นี่ไม่ใช่คำปรึกษาทางกฎหมาย และไม่ใช่การตรวจทานอย่างครอบคลุมหรือสรุปการตีความของไลเซนส์นี้ ก่อนจะดำเนินการใดๆ ตามเนื้อหาด้านล่าง ควรขอคำปรึกษาจากทนายความผู้เชี่ยวชาญ
    เงื่อนไขเริ่มต้นด้วยถ้อยคำทำนองว่าผู้ใช้ไม่มีโอกาสตรวจทานและยอมรับก่อนที่จะผูกพันตนเอง ธุรกิจ หรือองค์กร ซึ่งในสหรัฐฯ ดูเหมือนอาจทำให้เอกสารทั้งฉบับเป็นโมฆะได้ ดังนั้นจึงปลอดภัยกว่าที่จะให้ทนายความตรวจทานก่อนใช้งาน
    ในแวดวงวิชาการ เฉพาะนักศึกษาและคณาจารย์ของสถาบันนั้นเท่านั้นที่มีคุณสมบัติ และจากมุมมองของฝ่ายกฎหมาย การใช้ไลเซนส์นี้อาจถูกมองว่าเป็นการลงนามในสัญญาที่มีผลผูกพันแทนนายจ้าง
    ต้องตรวจสอบให้แน่ใจว่าไม่มีความเสี่ยงที่จะต้องรับผิดจากผู้ร่วมพัฒนาโอเพนซอร์ส หรือถูกไล่ออกเพราะแสดงตนอย่างไม่ถูกต้องว่าเป็นผู้มีอำนาจลงนามขององค์กร
    ผู้ใช้คลาวด์ตามเงื่อนไขถูกจำกัดไว้ที่ AWS และหากใช้บน GCP, Heroku หรืออินสแตนซ์เซิร์ฟเวอร์อื่นที่ไม่ได้อยู่ภายใต้การควบคุมตามสัญญาส่วนตัว อาจต้องจ่ายค่าไลเซนส์
    “Open Source” ที่อนุญาตในที่นี้มีเพียงตามนิยามของ OSI เท่านั้น ดังนั้นผู้ที่เผยแพร่ซอฟต์แวร์ภายใต้ไลเซนส์ไม่เชิงพาณิชย์แบบจำกัดจะไม่สามารถใช้ไลเซนส์ QNX แบบไม่ใช่เชิงพาณิชย์ได้
    ข้อกำหนด “ความเสี่ยงสูง” ห้ามพัฒนาแอปพลิเคชันที่อาจก่ออันตรายต่อสังคม ดังนั้น แอปโซเชียล ก็อาจถูกยกเว้นด้วย ต้องระวังไม่ให้ละเมิดข้อนี้ขณะสร้างแอปพลิเคชันที่มีโอกาสไวรัล
    มีการรวบรวมและเก็บรักษาหมายเลขซีเรียลทั้งหมดที่ระบุได้จากฮาร์ดแวร์ทุกชิ้นที่ใช้เกี่ยวข้องกับผลิตภัณฑ์นี้
    ไลเซนส์แบบไม่ใช่เชิงพาณิชย์สามารถถูกยุติได้ทุกเมื่อโดยไม่มีเงื่อนไข แม้จะปฏิบัติตามเงื่อนไขอย่างสุจริตก็ตาม และเมื่อถึงเวลานั้น อาจต้องจัดเตรียม “การรับรอง” ที่ไม่ได้ระบุนิยามว่าลบโค้ด QNX ทั้งหมดที่ได้รับมาแล้ว โดยมีค่าใช้จ่ายที่ไม่ทราบแน่ชัด

    • ไม่แน่ใจว่าแอปโซเชียลกลายเป็นความเสี่ยงสูงตั้งแต่เมื่อไร ข้อกำหนดความเสี่ยงสูง เห็นได้ชัดว่ามุ่งไปที่แอปพลิเคชันที่มีข้อกำหนดด้านความปลอดภัยอย่าง IEC 61508, ISO 26262
      ไคลเอนต์ Twitter ตายไปก็ไม่ได้ทำให้คนบาดเจ็บหรือตาย

  • ในเมื่อ Linux แบบเรียลไทม์ สุกงอมแล้ว ก็สงสัยว่ามีเหตุผลอะไรที่โปรเจกต์ใดควรใช้ QNX ต้องมาคอยกังวลว่าจะโดนหักหลังด้วยการเปลี่ยนไลเซนส์กะทันหันหรือ?
    ถ้าเป็นเพราะมันน่ารักและน่าสนใจเชิงวิชาการ ก็เคยใช้ QNX มาก่อน
    แต่ครั้งหน้าถ้าต้องเลือก SoC สำหรับโปรเจกต์และ BSP ที่มากับมัน คงไม่มองหา QNX น่าจะใช้ดิสทริบิวชัน FreeRTOS ที่แถมมา หรือไม่ก็ติดตั้งเครื่องมือบิลด์ของ Android แล้วดัน APK เข้าไปใน fork ของ Android แปลกๆ
    ถ้าเป็นสายยานยนต์หรือการแพทย์ก็อีกเรื่องหนึ่ง แต่ในสาขานั้นคู่แข่งก็ไล่ตามมาเรื่อยๆ และการเปลี่ยนแปลงด้านเรียลไทม์ของ Linux จะทำให้สถานการณ์ยากขึ้นอีก
    ตอนนี้ไม่ใช่ปี 2010 แล้ว มีตัวเลือกมากมาย และในขณะที่ QNX ยังอยู่หลังข้อกำหนดไลเซนส์ที่คลุมเครือและน่ารำคาญ บริษัทหลายสิบแห่งก็พัฒนาทางเลือกขึ้นมาแล้ว บางรายก็ใหญ่พอสมควร และบางตัวไปถึงอวกาศแล้วด้วย
    ตอนนี้ถ้า QNX อยากให้คนมองอย่างจริงจัง แค่ “เริ่มเปิดประตูของ QNX เหมือนเมื่อก่อน” ยังไม่พอ
    ถ้าไม่ใช่ โอเพนซอร์สเต็มรูปแบบรวมถึงการใช้งานเชิงพาณิชย์ ก็ไม่สนใจจะใช้ ถ้าเครื่องมือและการรองรับ BSP คุ้มค่ากับเวลา อาจยอมรับไลเซนส์แบบ Epic ได้บ้าง แต่ไม่มีความสนใจเลยที่จะจ่ายค่าไลเซนส์เพียงเพื่อเริ่มต้น
    ผลิตภัณฑ์กลายเป็นของทั่วไปแล้ว และตอนนี้เป็นแค่สิ่งที่น่าสนใจเล่นๆ หนทางเดียวที่จะได้การพัฒนาและการนำไปใช้ที่คึกคักเพียงพอ คือการกลายเป็นโปรเจกต์ของชุมชน

    • ชื่อและชื่อเสียงยังมีความหมายมากสำหรับบางคน และการไม่ต้องเรียนรู้ระบบปฏิบัติการอีกตัวก็สำคัญเช่นกัน
      ไม่ใช่ทุกคนจะใส่ใจเรื่องเสรีภาพหรือโอเพนซอร์ส และก็ไม่น่าแปลกใจที่แต่ละคนจะเอนเอียงไปคนละทางในเรื่องแบบนี้
    • ถ้าอยากได้งานด้าน การพัฒนาระบบปฏิบัติการเรียลไทม์ และอยากแสดงให้เห็นว่าจริงจังกับสายนี้ ก็อาจใช้ได้

  • ในบรรดาระบบปฏิบัติการที่เคยใช้ช่วงต้นทศวรรษ 2000 มีแค่ QNX กับ BeOS เท่านั้นที่ทำให้ Pentium แบบคอร์เดียวเก่า ๆ จากกลางยุค 90 รู้สึกยอดเยี่ยมและลื่นไหลได้
    ดีกว่า Windows เวอร์ชันไหน ๆ หรือ Linux มาก
    คิดว่าทั้งสองกรณีน่าจะเป็นเพราะ scheduler เป็นหลัก และมี multimedia stack ที่ดีกว่ามาก
    ผมหวังมาตลอดว่าระบบปฏิบัติการในอนาคตจะให้ความรู้สึกแบบนั้น แต่ที่ใกล้ที่สุดคงเป็น iOS และแม้แต่ตัวนี้ก็ใช้ทางลัดด้วยการคอยฆ่า process ทิ้ง อนาคตดูไม่ค่อยดีเลย

    • BeOS เป็นแบบ multi-threaded “โดยรวม” ซึ่งถ้าตัดคำการตลาดออกไปก็หมายความว่าใน kernel ไม่มี giant lock ตัวเดียวขนาดใหญ่ เพราะมันถูกออกแบบมาตั้งแต่แรกให้เป็นระบบ multi-core
      ระบบปฏิบัติการร่วมสมัยในตอนนั้นต่างก็มี giant lock ตัวเดียวขนาดใหญ่
      ผมจำไม่แน่ชัดว่า preemption interval ของ BeOS คือ 750ms หรือ 3ms แต่สั้นกว่า 20ms และต่อมา 10ms ของ Linux กับ Windows ดังนั้นจึงน่าจะเป็นเหตุผลที่รู้สึกถึงความต่างได้
      ผ่านมาหลายสิบปี ระบบปฏิบัติการส่วนใหญ่ไล่ตามระดับการล็อกที่ละเอียดขึ้นใน kernel space ได้แล้ว แต่ preemption interval ยังต่างกันอยู่เพราะข้อถกเถียงเรื่อง throughput เทียบกับ latency เนื่องจาก benchmark ระบบปฏิบัติการที่ใช้สคริปต์วัด throughput รวม ไม่ได้วัดความตอบสนองของ GUI
      media buffer ที่ได้ประโยชน์จาก buffer size เล็ก ๆ เป็นตัวอย่างที่ดี และแม้ throughput จะลดลง นักดนตรีก็สังเกตเห็นความตอบสนองที่ดีกว่าของ BeOS จึงได้ฉายาว่า “Media OS”
      ในฝั่ง GUI นั้น app server ของ BeOS/Haiku ก็ให้ workload ที่กระจายตัว มากกว่า desktop environment อื่น ๆ แต่ละหน้าต่างได้ thread ของตัวเอง แอปก็ได้ thread ของตัวเอง และทั้งแอปกับ application server จะมี thread หนึ่งต่อหนึ่งแอปและหนึ่งต่อหนึ่งหน้าต่าง เพื่อไม่ให้ค้างรอการ parse ข้อความจากแอปที่ช้า
      ดังนั้นแม้แต่แอป BeOS ขั้นต่ำที่มีหน้าต่าง “Hello World” แบบกราฟิกก็มี 4 threads แล้ว ต่อให้แอปยุ่งอยู่ ส่วนที่เหลือของระบบก็ยังรู้สึกตอบสนองได้ดี
      แต่ก็ต้องแลกด้วยต้นทุนด้าน throughput และความซับซ้อนในการพัฒนาแอป โดยเฉพาะกับแอปที่พอร์ตมา
      Haiku ต้องจัดเรียงข้อความ Qt/Gtk/toolkit จากหลายหน้าต่างให้เป็น message queue เดียวเพื่อป้องกันบั๊ก multi-threaded เพราะใน environment เดิม app message loop ไม่ได้เป็น multi-threaded
      การจัดเรียงนี้ทำให้ใน Haiku ต้องมีการเรียก lock/unlock เพิ่ม แม้ในกรณีที่ไม่จำเป็น เช่น ข้อความที่ส่งไปยังหน้าต่างเดียวกัน
      ในทางกลับกัน แอป native ของ Haiku นั้นลื่นราวกับน้ำแข็ง นี่คือ screenshot ของโปรแกรมตัดต่อวิดีโอ Medo ที่ทุกหน้าต่างทำงานใน thread ของตัวเอง: https://raw.githubusercontent.com/smallstepforman/Medo/refs/...
      บนระบบสมัยใหม่ แอปนี้ลื่นราวกับน้ำแข็ง ซึ่งสำหรับโปรแกรมตัดต่อวิดีโอแล้วแทบจะนอกรีต แอป Haiku ที่ลิงก์ไว้นั้นผมเป็นคนเขียนเอง
    • ผมฝันจริง ๆ ว่าจะมีวันที่คอมพิวเตอร์สมัยใหม่บูตได้เร็วเหมือน Commodore 128 ในอดีต รีเซ็ตก็เร็ว และตอบสนองต่อการกดปุ่มทุกครั้งอย่างลื่นไหล
    • ถึงจะใช้ทางลัด แต่ก็ต้องยอมรับว่าพยายามอยู่
      ผมเลิกใช้ Android ตอนที่แม้แต่ Samsung ก็ยังไม่พยายามจริงจังในการปรับปรุงความตอบสนองของโทรศัพท์
      เป็นเรื่องดีที่ Apple ให้ความสำคัญกับความตอบสนองอย่างสม่ำเสมอ และเพราะแบบนั้น Google, Samsung, Microsoft ก็มีแรงจูงใจให้แก้ผลิตภัณฑ์ที่บวมเทอะทะของตัวเอง
    • ในฐานะคนที่เคยใช้ BeOS กับ OS/2 Warp ผมคิดถึง ความลื่นไหลฉับไว ของระบบยุคก่อน QNX ผมยังไม่เคยลองจับเอง
      ในบรรดาระบบปฏิบัติการทุกวันนี้ อะไรใกล้เคียงกับความลื่นไหลฉับไวนั้นที่สุดนะ? Haiku OS หรือเปล่า?
      ผมใช้ M1 MacBook ได้ดี แต่บางครั้งก็รู้สึกว่ายังไม่พอ
    • ผมไม่เคยรัน QNX แต่ประสบการณ์ที่ Pentium 90 รู้สึกยอดเยี่ยมมากบน BeOS นั้นคล้ายกัน
      อีกตัวอย่างหนึ่งคือ SGI IRIX ซึ่งมี scheduler ที่ดีผิดปกติ ผมเคยใช้เครื่อง 30MHz อยู่พักหนึ่ง และ desktop ก็ค่อนข้างลื่นไหล
      วันหนึ่งผม compile AMP แล้วใส่รายการ MP3 ที่ส่วนใหญ่เป็น 192kbps เข้าไป ซึ่งโปรแกรมนี้ถอดรหัส 256kbps ได้แบบไม่สะดุดด้วย
      ไฟล์อยู่บน NFS share และเมื่อรัน gr_osview ดู พบว่า CPU usage อยู่ที่ 95% แต่ file manager ยังตอบสนอง และเพลงก็ไม่สะดุด
      แค่ถอดรหัส MP3 bitrate สูงกว่า 192kbps บน 30MHz ได้ก็น่าประทับใจแล้ว
      การที่ยังคงตอบสนองได้ทั้งที่เปิด desktop ของ X Window System เต็มรูปแบบและเล่นไฟล์จาก NFS share แสดงให้เห็น network stack กับ scheduler ที่เบาและแข็งแกร่ง ซึ่งทำงานได้ดีแม้บนฮาร์ดแวร์สเปกต่ำ
      เป็น IRIX 5.3 บน Indigo Elan
      เพื่อนกับผมชอบระบบปฏิบัติการ เราเลยรัน BeOS บน Pentium 90 เก่า ๆ และอย่างที่พูดไป มันลื่นไหล
      Linux ก็มีส่วนเหมือนกัน หลังจากโดนน้ำทำให้เสียหาย Pentium 90 เครื่องนั้นก็ไม่เสถียรอีกต่อไป และเพราะใช้ RAM ที่ไม่มี parity Windows NT จึงค่อย ๆ เพี้ยนแล้ว blue screen ซ้ำ ๆ
      เพื่อความสนุก เราลง Red Hat 5.2 แล้วมันก็ทำงานได้ดี system log มีรายการจำนวนมากถูกบันทึกทุกวินาที และสามารถเปิด X console ดูมันไหลผ่านไปได้เฉย ๆ
      เครื่องนั้นยังให้บริการเว็บเพจของบริษัทอยู่หลายสัปดาห์เพื่อความสนุกด้วย เป็นช่วงเวลาดี ๆ

  • ขอเสริมรายละเอียดว่า ซอร์สโค้ดของ QNX เคยเข้าถึงได้ตั้งแต่ปี 2007 จนถึงก่อนการเข้าซื้อโดย RIM/Blackberry ในปี 2010
    มีแผนจะเปิดให้เข้าถึงซอร์สโค้ดของ QNX อีกครั้งในอนาคตไหม?
    https://www.qnx.com/news/pr_2471_1.html

    • อยากให้ไม่ต้องยืนยันกำหนดการแน่นอน แต่ชัดเจนว่ากำลังไปในทิศทางที่ เปิดกว้างและโปร่งใสมากขึ้น
      เราได้ยินมาว่าเรื่องนี้สำคัญทั้งต่อลูกค้าและชุมชน โปรดติดตามต่อไป

  • บริษัทเดิมของผมเคยทำเราเตอร์ Active/Standby ความพร้อมใช้งานสูงสำหรับเครือข่ายมือถือ และใช้ QNX เป็นระบบปฏิบัติการ ความสามารถนั้นยังน่าประทับใจอยู่จนถึงตอนนี้
    ความทรงจำอาจเลือนรางไปบ้าง แต่เราใช้ QNX บนโปรเซสเซอร์ฝั่ง control plane และรองรับแบบ native สำหรับการสตาร์ตโปรเซสบนโปรเซสเซอร์ระยะไกลผ่านเครือข่ายภายในของเราเตอร์
    กล่าวคือ การสื่อสารระหว่างโปรเซส ระดับต่ำสามารถใช้ IP ได้ และ IPC ของ QNX ก็เป็นสิ่งจำเป็นต่อฟังก์ชัน failover ความพร้อมใช้งานสูง
    การที่ไดรเวอร์อุปกรณ์เป็นโปรเซสใน user space และสามารถรีสตาร์ตได้เมื่อแครชก็ยอดเยี่ยมเช่นกัน ตอนนั้นกำลังพัฒนาไดรเวอร์เครือข่ายอยู่ เลยมีเหตุการณ์แบบนั้นเกิดขึ้นจริงเป็นบางครั้ง
    อีกอย่างที่ดีกว่าคืออุปกรณ์ปรากฏอยู่ใน tree /dev/ จริง ๆ ต่างจากบน Linux ที่อุปกรณ์เครือข่ายเป็นข้อยกเว้นและไม่ได้ปรากฏอย่างถูกต้องใน tree /dev/
    เรื่องเล่าขำ ๆ คือครั้งหนึ่งเกิดปัญหาเพราะผมเผลอใส่ const ให้ค่าที่คืนจาก IPC ทำให้โปรเซสของผมตายอยู่ระหว่างฟังก์ชัน IPC ของ QNX กับฟังก์ชันของผมเอง
    ดีบักอยู่หลายวัน และด้วยระดับของดีบักเกอร์ C/user space ที่ใช้ในตอนนั้น ก็จับข้อผิดพลาดนั้นไม่ได้

    • ผมก็เคยทำงานกับเราเตอร์สำหรับเครือข่ายมือถือเหมือนกัน ทุกอย่างรันบน Linux และ control plane ก็เป็น Linux
      line card ก็เป็น Linux เช่นกัน แต่ทำแค่โปรแกรม ASIC ตามที่ control plane สั่ง
      ฟังก์ชันแบบนั้นไม่ได้เกี่ยวข้องเป็นพิเศษ และ IPC จะทำผ่าน HTTP หรือวิธีไหนก็ได้ตามต้องการ
    • การสตาร์ตโปรเซสบนโปรเซสเซอร์ระยะไกลผ่านเครือข่ายภายในนั้น ทำได้แล้วใน CP/NET(https://en.wikipedia.org/wiki/MP/M#CP/NET) หรือ CP/J ที่มี JUNET ([https://pl.wikipedia.org/wiki/JUNET_(CP/J)) เช่นกัน

  • @JohnAtQNX ช่วยเอาข้อจำกัดในส่วนดาวน์โหลดของเว็บไซต์ที่ว่า ทุกอย่างต้องมีบัญชี ออก และเอากลไกไลเซนส์ของ qcc ออกได้ไหม?
    มันจะช่วยได้มากในการกระตุ้นให้นักพัฒนาสายงานอดิเรกลองใช้งาน
    รายได้น่าจะมาจากสัญญาไลเซนส์จำนวนมาก และน่าจะเป็นโครงสร้างที่เก็บค่าไลเซนส์ต่ออุปกรณ์ปลายทาง
    ถ้าทำให้ทีม CI/CD ที่ต้องรองรับชุดผลิตภัณฑ์ QNX ไม่พอใจ แหล่งรายได้นั้นก็จะตกอยู่ในความเสี่ยง

    • เราเคยคุยกันภายในว่าจะทำให้เป็นไปได้อย่างไร
      ดีที่ได้ยินเรื่องเดียวกันจากภายนอกด้วย ผมจะนำกลับขึ้นโต๊ะอีกครั้งและค่อย ๆ ผลักดันต่อไป
    • อย่างน้อยให้ล็อกอินด้วยบริการอื่นอย่าง Google ได้ก็น่าจะดี หลายเว็บก็ทำแบบนั้นอยู่แล้ว
      ผมเกลียดมากที่ทุกครั้งมีอะไรใหม่ ๆ โผล่มา ก็ต้องเพิ่มล็อกอินใหม่ไปเรื่อย ๆ
      news feed ก็เหมือนกัน เว็บข่าวเกือบครึ่งอ้างว่า “ฟรี” แต่ก็ยังต้องล็อกอิน กรณีนั้นยังพอทนกว่า เพราะมักหาบทความเดียวกันจากที่อื่นได้ง่าย
    • ใช่แล้ว มีโอกาสสูงกว่าที่คนจะไปที่อื่นที่มีแรงเสียดทานน้อยกว่า

  • ผมยังจำได้ว่าทึ่งกับ เดโม QNX ในฟลอปปีดิสก์แผ่นเดียว ที่ถึงขั้นมีเว็บเบราว์เซอร์อยู่ด้วย มันเร็วมากจริง ๆ
    ขอให้ไปได้สวย แค่จินตนาการก็พอเห็นแล้วว่าการสะสางประเด็นทางกฎหมายทั้งหมดเพื่อเปิดอะไรบางอย่างจริง ๆ จะเป็นปมกอร์เดียนที่ยุ่งยากแค่ไหน
    อย่างที่คนอื่น ๆ พูดกัน ทุกคนระมัดระวังเพราะเคยโดนหักหลังมาสองครั้งแล้ว แต่ QNX มีหลายอย่างให้น่าสนุก หวังว่าครั้งนี้จะได้แรงส่งจริง ๆ

    • ฟลอปปีดิสก์เดโม QNX ช่วงปลายยุค 90 นั้น เหมือนเวทมนตร์ เลย มันแสดงให้เห็นว่าเมื่อเทียบกับ Linux/Windows ในตอนนั้น บน CPU 486 DX2 หรือ DX4 จะรู้สึกเร็วได้แค่ไหน
      หลังจากนั้นผมก็มีความประทับใจเชิงบวกกับ QNX อยู่พอสมควร แต่การเปลี่ยนเจ้าของกลางทางและการเปลี่ยนสถานะระหว่างเปิดเผย/เชิงพาณิชย์ ทำให้ผมคอยเว้นระยะอยู่เสมอ
      น่าเสียดายที่ “การเปิด” ครั้งนี้ก็ให้ความรู้สึกคุ้นเคย และถ้าไม่เกิดชุมชนเสรีและโอเพนซอร์สขนาดใหญ่พอที่จะรักษาไลเซนส์ GPL ที่เปิดจริงและฟอร์กไว้ได้ ผมก็มองว่ามันจะถูกถอนกลับอีก

  • ชอบความพยายามที่กล้าทำแบบนี้ ผมเฝ้ามอง QNX ด้วยความสนใจอยู่ข้าง ๆ มานานแล้ว แต่ในกรณีส่วนใหญ่ก็ไม่ใช่ผู้ใช้ที่มีแนวโน้มจะใช้จริง
    ก้าวถัดไปที่ดีน่าจะเป็นซีรีส์บทความบล็อกที่เลือกประเภทโปรเจกต์งานอดิเรกที่พบได้บ่อย แล้วอธิบายว่าในบริบทนั้นจะนำ จุดแข็งของ QNX ไปใช้ได้อย่างไร

    • ผมก็อยากเห็นบทความแบบนั้นเหมือนกัน ผมสนใจ QNX แต่ในฐานะคนที่เล่นหุ่นยนต์ที่บ้าน ยังไม่ค่อยเห็นภาพว่ามันจะมีประโยชน์อะไรกับผม
      ผมยังทำงานกับองค์กรไม่แสวงหากำไรที่ทำวิจัยการเฝ้าระวังชายฝั่งด้วย ซึ่งมีบางคนทำฮาร์ดแวร์แบบกำหนดเอง มันจะช่วยเราได้ไหม?

  • พวกเรา Rizin อยากปรับปรุงการรองรับ QNX ใน เฟรมเวิร์ก reverse engineering และดีบักแบบเสรีและโอเพนซอร์ส
    ตอนนี้รองรับอยู่แล้ว[1][2][3][4] แต่ไม่สามารถทดสอบได้อย่างเสถียร
    ถ้ามีอิมเมจ QEMU มาให้โดยพื้นฐานคงดี เหมือนที่ Windows มี VM แบบจำกัดไว้สำหรับทดสอบให้ใช้ได้ทันที[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...

    • ด้วย ไลเซนส์ QNX Everywhere ฟรี น่าจะสามารถเปิด QEMU VM จาก IDE ได้ด้วยการคลิกไม่กี่ครั้ง
      อย่างไรก็ตาม ผมเข้าใจว่าการดาวน์โหลดแบบคลิกเดียวเหมือนอิมเมจ Windows จะง่ายกว่า และจะนำฟีดแบ็กนี้กลับไป
      ถ้ามีวิธีอื่นที่เราจะช่วยให้การรองรับ QNX เป็นไปได้ โปรด DM หรือส่งข้อความไปที่ qnxcommunityengagement at qnx dot com