1 điểm bởi GN⁺ 2024-11-08 | 1 bình luận | Chia sẻ qua WhatsApp
  • Các nhà phát triển hệ điều hành nhúng và thời gian thực có thể thử nghiệm QNX SDP 8.0 miễn phí cho mục đích sinh viên, sở thích cá nhân và tạo prototype, giúp giảm rào cản tiếp cận vốn trước đây chủ yếu xoay quanh thương mại
  • Người dùng phải gửi biểu mẫu giấy phép bằng tài khoản myQNX; sau khi yêu cầu được xử lý, họ sẽ nhận giấy phép phần mềm QNX cho mục đích phi thương mại
  • Phạm vi cung cấp bao gồm QNX SDP 8.0, QNX Developer Desktop và QNX Hypervisor, cho phép đi từ học hệ điều hành đến phát triển self-hosted và thử nghiệm ảo hóa
  • Tài nguyên khởi đầu gồm Quick Start Guide, image QNX 8.0 cho Raspberry Pi, video QNX Everywhere và Self-Hosted Developer Desktop Guide
  • Giấy phép miễn phí chỉ giới hạn cho giáo dục, dự án cá nhân và học RTOS; đánh giá hoặc phát triển cho mục đích thương mại phải đăng ký giấy phép đánh giá 30 ngày riêng

Cung cấp môi trường phát triển QNX cho mục đích phi thương mại

  • QNX Everywhere là chương trình cho phép sinh viên, nhà phát triển theo sở thích và người làm prototype sử dụng phần mềm QNX miễn phí cho mục đích phi thương mại
  • Đối tượng được cung cấp gồm hệ điều hành thế hệ tiếp theo của QNX, công cụ phát triển và các tính năng thời gian thực; có thể dùng để học tập, thử nghiệm và xây dựng các dự án nhúng hiệu năng cao
  • Các số liệu công khai gồm 15K+ lượt tải giấy phép QNX Everywhere, 6K+ học viên đã đăng ký các khóa đào tạo trực tuyến và 100+ tổ chức học thuật hợp tác

Quy trình đăng ký giấy phép

  • Để nhận giấy phép phi thương mại, cần có tài khoản myQNX
    • Nếu đã có tài khoản, hãy đăng nhập
    • Nếu lần đầu sử dụng QNX, hãy tạo tài khoản myQNX
  • Sau khi đăng nhập, bắt đầu yêu cầu bằng cách nhập dữ liệu giấy phép vào biểu mẫu giấy phép QNX Everywhere
  • Khi yêu cầu được xử lý xong, bạn sẽ nhận giấy phép phần mềm QNX để sử dụng phi thương mại
  • Sau khi yêu cầu, có thể mất tối đa 1 giờ để giấy phép hiển thị trong hồ sơ myQNX

Nền tảng và công cụ được bao gồm

  • QNX SDP 8.0 là nền tảng phát triển cơ sở cho các SoC thế hệ tiếp theo
    • Bao gồm QNX Operating System thế hệ tiếp theo
    • Nêu bật kiến trúc được thiết kế để tận dụng các bước tiến silicon trong tương lai
    • Mục tiêu là cung cấp hiệu năng thời gian thực nhất quán trên các hệ thống đòi hỏi nhiều năng lực tính toán trong toàn bộ lĩnh vực IoT
    • Bao gồm toolchain được nâng cấp, các tiện ích mới để debug và profiling, cùng các tiện ích mã nguồn mở
  • QNX Everywhere bao gồm quyền truy cập vào:
    • QNX SDP 8.0: nền tảng microkernel RTOS hiệu năng cao, sẵn sàng cho an toàn
    • QNX Developer Desktop: desktop self-hosted để xây dựng ứng dụng trên QNX OS 8.0
    • QNX Hypervisor: hypervisor tất định cho các hệ thống mixed-criticality

Giáo dục, cộng đồng và mã nguồn mở

  • QNX cung cấp các khóa đào tạo trực tuyến miễn phí cho nhà phát triển QNX OS
  • Nhà phát triển có thể kết nối với kỹ sư QNX và cộng đồng nhà phát triển trực tuyến để giải quyết vấn đề, thảo luận ý tưởng và cộng tác trong các dự án mã nguồn mở
  • Vì là hệ điều hành tương thích POSIX, phần lớn phần mềm dành cho hệ điều hành POSIX có thể được biên dịch cho QNX với rất ít chỉnh sửa
  • QNX công bố mã nguồn của các bản port mã nguồn mở theo giấy phép gốc, đồng thời duy trì các bản port mà nhà phát triển có thể sử dụng tại GitHub repository
  • Có thể kiểm tra thông tin về bản port, mức độ kiểm thử và chi tiết hosting tại Open-Source Dashboard

Bắt đầu với tài liệu và image Raspberry Pi

  • Tài liệu QNX Everywhere cung cấp các công cụ và hướng dẫn cần thiết để xây dựng từ ứng dụng đầu tiên đến các giải pháp QNX nâng cao
  • Các tài nguyên được cung cấp gồm:
  • Người dùng Raspberry Pi 5 có thể flash và sử dụng image QNX SDP 8.0 đã chuẩn bị sẵn
    • Image bao gồm nhiều ứng dụng demo mã nguồn mở
    • Có thể clone, chỉnh sửa và build lại các ứng dụng demo

Điều kiện sử dụng và các đối tượng không được bao gồm

  • Giấy phép miễn phí dành cho người dùng cá nhân phi thương mại đối với QNX Software Development Platform 8.0
  • Mục đích sử dụng được phép gồm giáo dục, dự án cá nhân và các hoạt động không tạo doanh thu hoặc vận hành kinh doanh
  • Sử dụng phi thương mại bao gồm môi trường học thuật, nhà phát triển theo sở thích và người học hệ điều hành thời gian thực
  • Không bao gồm đánh giá hoặc phát triển cho mục đích thương mại
    • Hoạt động thương mại bao gồm tạo doanh thu hoặc vận hành kinh doanh
    • Giấy phép đánh giá 30 ngày cho mục đích thương mại là đối tượng phải đăng ký riêng
  • QNX SDP 7.1 không nằm trong chương trình này
    • QNX SDP 8.0 được cung cấp cho các nền tảng phần mềm thế hệ tiếp theo dựa trên SoC có từ 4 lõi CPU trở lên

Cài đặt nhiều máy tại cơ sở giáo dục

  • Nếu muốn thiết lập nhiều workstation trong phòng lab hoặc lớp học, có thể nhận giấy phép nhiều người dùng thông qua chương trình QNX in Education
    • Đối tượng bao gồm QNX Software Development Platform 8.0 và QNX Software Development Platform 7.1
  • Nếu chỉ cài đặt một instance tại một thời điểm, nên sử dụng giấy phép QNX Everywhere

Xử lý vấn đề tài khoản và giấy phép

  • Nếu gặp vấn đề đăng nhập sau khi đăng ký tài khoản myQNX mới, hãy liên hệ myqnx@blackberry.com
  • Có thể kiểm tra và chấp nhận trạng thái giấy phép và phân phối sản phẩm trong myQNX License Manager
  • Phần Registered Products trong hồ sơ tài khoản myQNX hiển thị license key, serial number, license certificate và license manager cho từng sản phẩm đã được phân phối
  • Để tải QNX Software Center, người dùng myQNX phải được gán giấy phép sản phẩm QNX

1 bình luận

 
GN⁺ 2024-11-08
Ý kiến trên Hacker News
  • Sẽ rất tuyệt nếu có thể tin được, nhưng QNX từng “mở ra” rồi lại đóng lại đến hai lần
    Trước lần rút lại đầu tiên, các dự án nguồn mở thường đưa QNX vào danh sách mục tiêu build, và cũng có thể hỗ trợ target Firefox và Eclipse cho QNX, cũng như build GCC và các công cụ dòng lệnh GNU
    Họ còn có một môi trường desktop tên là Photon, và khi làm xe cho DARPA Grand Challenge, tôi đã dùng nó làm desktop chính trong 3 năm
    Nhưng sau khi Harman mua lại QNX vào năm 2004, tất cả biến mất; đến năm 2007 mã nguồn lại được mở, thậm chí có thể xem và build cả microkernel, nhưng đó không phải là giấy phép mở
    Năm 2010, khi RIM mua lại QNX, họ đóng mã nguồn mà không báo trước; mọi phát triển nguồn mở liên quan đến QNX đều dừng lại, và niềm tin của cộng đồng cũng mất theo
    Điều khoản hợp đồng cũng là vấn đề: http://www.qnx.com/download/feature.html?programid=51624 ghi rằng “TERMINATION. This Agreement and licenses granted hereunder may be terminated by either Party upon written notice to the other Party”, nghĩa là QNX có thể cắt bất cứ lúc nào
    Nếu QNX nghiêm túc, có lẽ nên đi theo kiểu giấy phép của Unreal Engine. Tải mã nguồn về và dùng tùy ý; miễn phí cho đến khi doanh thu sản phẩm đạt 1 triệu USD, sau đó Epic thu 5% tiền bản quyền: https://cdn2.unrealengine.com/UnrealEngine/faq/UnrealEngineE...
    Vấn đề sao chép lậu cũng không quá lớn, vì khi một trò chơi tạo ra doanh thu đáng kể thì sẽ đủ nổi bật để người phụ trách giấy phép biết đến
    Nếu muốn tăng mức độ được dùng của QNX, họ nên mang bảng điều kiện của Epic đến cho đội pháp lý và ban lãnh đạo, rồi so sánh tăng trưởng doanh thu của Unreal Engine với QNX
    Như tôi từng nói với một nhân viên kinh doanh QNX, vấn đề của QNX không phải là bị sao chép lậu, mà là bị phớt lờ

    • Năm 2011 tôi làm ở một startup Đức bị RIM/Blackberry mua lại; công ty muốn toàn bộ nhân viên ký hợp đồng mới giữ nguyên vai trò và lương, nhưng hợp đồng đó có các hạn chế về quyền sở hữu trí tuệ rất nặng
      Mọi hoạt động nguồn mở đều bị cấm, trong khi lúc đó nhiều người trong chúng tôi đang tham gia rất tích cực vào nguồn mở. Tôi cũng từng làm việc tại Eclipse Foundation
      Một người bạn viết tiểu thuyết được nói rằng mỗi lần đăng hoặc xuất bản một bài viết đều cần có giấy phép bằng văn bản
      Dù có bản dịch tiếng Đức đính kèm, họ vẫn ép các kỹ sư Đức ký một hợp đồng mà ngôn ngữ có hiệu lực ràng buộc là tiếng Anh; cuối cùng rất nhiều người trong chúng tôi cứ thế rời đi
      Điều tôi nhớ nhất là nhóm chuyển tiếp từ Canada nói rằng “nhân viên RIM làm việc trong những ngục tối bê tông tối tăm, nên các bạn may mắn biết bao khi vẫn được dùng văn phòng đẹp ở Munich”
      Trong DNA của công ty đó, cách làm mở dường như hoàn toàn xa lạ, và tôi sẽ không tin họ chút nào
    • Một lựa chọn là cấp phép kép GPLv3 và giấy phép thương mại. Số “3” trong GPLv3 rất quan trọng
      Các lập trình viên sở thích và các dự án tự do/nguồn mở sẽ sẵn lòng dùng hệ điều hành GPLv3, còn các khách hàng thương mại lớn truyền thống trong mảng ô tô/nhúng sẽ không muốn nghĩa vụ GPLv3 buộc họ phải cho phép người dùng cài firmware tùy chỉnh, nên họ sẽ tiếp tục trả phí
      Việc này có thể có lợi cho tất cả
      Đây không phải tư vấn pháp lý; mỗi người cần tự diễn giải giấy phép
    • Trong DNA tổ chức của RIM/Blackberry đã khắc sẵn trải nghiệm nhà phát triển tệ hại
      Tôi từng nói chuyện khá lâu với các kỹ sư trước khi BB10 ra mắt; nếu nhớ không nhầm, lúc đó muốn truy cập toàn bộ Blackberry SDK thì phải nộp đơn và ký NDA
      Trong khi đó Android và iOS đã phát triển mạnh, và bên ưu tiên nền tảng dễ viết ứng dụng đã thành công
      Blackberry có vẻ bất lực về mặt tổ chức trong việc xử lý mối quan hệ với cộng đồng kiểu này. Tư duy kiểu nhà mạng “chúng ta đối đầu với họ” nằm ở tầng trên của tổ chức, rồi thấm xuống dưới, dù là rõ ràng hay ngầm ẩn
    • Nếu là trước năm 2004, QNX vẫn còn có thể chiếm một vị trí đáng kể. Đó là thời kỳ người dùng và nhà phát triển còn thử nghiệm các hệ điều hành, và QNX có thể thu hút đủ người để tạo ra một ngách cả trên desktop
      Sau khi BeOS thất bại, tôi đã nghịch và phát triển với QNX, thậm chí thích đến mức dùng toàn thời gian trên máy phát triển chính
      Nhưng khi nó bị đóng lại, tôi đã bị bỏng nặng, và từ đó không đụng đến bất kỳ nền tảng phát triển đóng nào nữa
      Nhìn giấy phép hiện nay thì chẳng có gì thay đổi, và giờ ngoài thị trường sẵn có, QNX nhìn chung đã kém liên quan hơn nhiều
      Chọn QNX hôm nay trông thật dại dột. Giờ đã có những lựa chọn thay thế tốt, và tất cả đều có giấy phép mở
    • Tôi cũng tò mò thực tế có bao nhiêu ứng dụng cần khả năng đáp ứng thời gian thực mạnh hơn Linux
      Giờ đã có https://arstechnica.com/gadgets/2024/09/real-time-linux-is-o... nữa
      Dùng Linux thì không cần bàn chuyện giấy phép, cũng không phải lo bị đâm sau lưng rồi đột ngột bị đóng lại
      Cấm sử dụng thương mại là điều khủng khiếp. Hiện tôi đang gặp chuyện tương tự với ArangoDB; sản phẩm thì tốt, nhưng tôi không có ngân sách cho instance cloud do họ quản lý, cũng không có ngân sách để thảo luận giấy phép thương mại với đội bán hàng
      Tôi đang dùng nó trong nhiều hệ thống; một trong số đó đã đạt khoảng 80% ngưỡng của cơ sở dữ liệu “quá lớn để dùng miễn phí”, nhưng tôi không biết số phận của nó sẽ là nguồn mở, thành sản phẩm, hay thành một hệ thống trực tiếp kiếm tiền
      Vì vậy, con đường ngắn trước mắt không phải là nói chuyện với những người có thể không cho phép mô hình kinh doanh của tôi, mà là chuyển sang PostgreSQL
  • Nếu muốn xem ngay các điều khoản dành cho nhà phát triển liên quan đến việc sử dụng phi thương mại QNX 8.0 thì ở đây: https://support7.qnx.com/download/download/51624/BB_QNX_Deve...
    Đây không phải tư vấn pháp lý, cũng không phải bản rà soát toàn diện hay tóm tắt diễn giải về giấy phép này. Trước khi hành động dựa trên nội dung dưới đây, bạn nên nhận tư vấn chuyên môn từ luật sư
    Các điều khoản mở đầu bằng một điều khoản kiểu như người dùng không có cơ hội xem xét và đồng ý trước khi ràng buộc bản thân/doanh nghiệp/tổ chức của mình; ở Mỹ, điều này có vẻ có thể làm vô hiệu toàn bộ văn bản, nên an toàn nhất là rà soát với luật sư trước khi dùng
    Trong giới học thuật, chỉ sinh viên và giảng viên của tổ chức đó mới đủ điều kiện, và việc sử dụng giấy phép này có thể bị bộ phận pháp chế xem là đã ký một hợp đồng có tính ràng buộc thay mặt cho chủ lao động
    Cần chắc chắn rằng bạn sẽ không phải chịu trách nhiệm vì các cộng tác viên mã nguồn mở, hoặc không có nguy cơ bị sa thải vì tự nhận sai mình là người có thẩm quyền ký của tổ chức
    Người dùng đám mây theo điều khoản bị giới hạn ở AWS; nếu dùng trên GCP, Heroku hoặc các phiên bản máy chủ khác không nằm dưới sự kiểm soát bằng hợp đồng cá nhân, bạn có thể phải trả phí giấy phép
    “Open Source” được cho phép ở đây chỉ là theo định nghĩa của OSI, nên những người phân phối phần mềm theo giấy phép phi thương mại có tính hạn chế không thể dùng giấy phép phi thương mại của QNX
    Điều khoản “rủi ro cao” cấm phát triển các ứng dụng có thể gây hại cho xã hội, nên ứng dụng mạng xã hội cũng có thể bị loại trừ. Cần cẩn thận để không vi phạm điều khoản này khi tạo ứng dụng có tính lan truyền
    Họ thu thập và lưu giữ mọi số sê-ri có thể nhận dạng trên tất cả phần cứng được dùng liên quan đến sản phẩm này
    Giấy phép phi thương mại có thể bị chấm dứt bất cứ lúc nào mà không kèm điều kiện nào, ngay cả khi đã tuân thủ thiện chí các điều kiện; khi đó bạn có thể phải cung cấp một “chứng nhận” không được định nghĩa rõ rằng đã xóa toàn bộ mã QNX được cung cấp, với chi phí không rõ

    • Không rõ từ bao giờ ứng dụng mạng xã hội lại thành rủi ro cao. Điều khoản rủi ro cao rõ ràng nhắm đến các ứng dụng có yêu cầu an toàn như IEC 61508, ISO 26262
      Một client Twitter có chết thì cũng không làm ai bị thương hay tử vong
  • Trong bối cảnh Linux thời gian thực đã trưởng thành, tôi tự hỏi có dự án nào còn lý do để dùng QNX không. Có đáng phải bận tâm để rồi bị đâm sau lưng khi họ bất ngờ đổi giấy phép không?
    Vì dễ thương và thú vị về mặt học thuật thì trước đây tôi từng dùng QNX
    Nhưng lần tới khi chọn SoC cho dự án và BSP đi kèm, tôi sẽ không tìm đến QNX. Có lẽ tôi sẽ dùng bản phân phối FreeRTOS đi kèm, hoặc cài công cụ build Android rồi đẩy APK vào một bản fork Android kỳ quặc nào đó
    Nếu là lĩnh vực ô tô hay y tế thì câu chuyện sẽ khác, nhưng ở những lĩnh vực đó các đối thủ cũng liên tục bám đuổi, và các thay đổi thời gian thực của Linux sẽ khiến tình hình còn khó khăn hơn
    Bây giờ không còn là năm 2010 nữa. Có rất nhiều lựa chọn, và trong lúc QNX vẫn đứng sau các yêu cầu giấy phép mơ hồ và khó chịu, hàng chục công ty đã phát triển các phương án thay thế. Một số trong đó khá lớn, và có cái còn đã lên tới không gian
    Giờ để QNX được xem xét nghiêm túc thì chỉ “bắt đầu mở cửa QNX như trước đây” là chưa đủ
    Nếu không phải mã nguồn mở hoàn toàn cả cho sử dụng thương mại thì tôi không có hứng thú dùng. Nếu công cụ và hỗ trợ BSP đáng với thời gian bỏ ra thì tôi có thể chấp nhận kiểu giấy phép giống Epic, nhưng tôi hoàn toàn không muốn trả phí giấy phép chỉ để bắt đầu
    Sản phẩm đã bị hàng hóa hóa và giờ chỉ còn là thứ để tò mò. Con đường duy nhất để có đủ phát triển và chấp nhận tích cực là trở thành một dự án cộng đồng

    • Tên tuổi và danh tiếng vẫn rất có ý nghĩa với một số người, và việc không phải học thêm một hệ điều hành khác cũng quan trọng
      Không phải ai cũng quan tâm đến chuyện tự do/mã nguồn mở, và cũng không ngạc nhiên khi mỗi người nghiêng về một hướng khác nhau trong các vấn đề kiểu này
    • Có thể dùng nếu muốn kiếm việc trong mảng phát triển hệ điều hành thời gian thực và muốn thể hiện rằng mình thật sự nghiêm túc với lĩnh vực đó
  • Trong số các hệ điều hành tôi từng dùng vào đầu những năm 2000, chỉ có QNX và BeOS khiến một chiếc Pentium đơn nhân cũ kỹ từ giữa thập niên 90 cho cảm giác tuyệt vời và nhanh nhạy
    Tốt hơn rất nhiều so với bất kỳ phiên bản Windows hay Linux nào
    Tôi nghĩ trong cả hai trường hợp, chủ yếu là nhờ bộ lập lịch và stack đa phương tiện tốt hơn hẳn
    Tôi luôn mong các hệ điều hành tương lai sẽ có cảm giác như vậy, nhưng thứ gần nhất có lẽ là iOS, mà nó cũng dùng mẹo là liên tục kill các tiến trình. Tương lai chẳng hay ho lắm

    • BeOS “nhìn chung” là đa luồng; nếu bỏ lớp ngôn từ marketing đi thì nghĩa là kernel không có một khóa đơn khổng lồ. Vì ngay từ đầu nó được thiết kế cho hệ thống đa nhân
      Các hệ điều hành cùng thời khi đó đều có một khóa đơn khổng lồ
      Tôi không nhớ chắc khoảng preemption của BeOS là 750ms hay 3ms, nhưng nó ngắn hơn 20ms, rồi sau đó 10ms của Linux và Windows, nên hẳn vì thế mà cảm nhận được khác biệt
      Vài chục năm sau, hầu hết hệ điều hành đã bắt kịp mức khóa mịn hơn trong không gian kernel, nhưng khoảng preemption vẫn khác nhau do cuộc tranh luận throughput so với latency. Vì các benchmark hệ điều hành dựa trên script đo throughput tổng thể chứ không đo độ phản hồi GUI
      Bộ đệm media được lợi từ kích thước buffer nhỏ là một ví dụ hay; dù throughput giảm, các nhạc sĩ vẫn nhận ra độ phản hồi tốt hơn của BeOS, vì thế nó có biệt danh “Media OS”
      Trong không gian GUI, app server của BeOS/Haiku cũng cung cấp tải công việc phân tán hơn các môi trường desktop khác. Mỗi cửa sổ có luồng riêng, ứng dụng cũng có luồng riêng, còn ứng dụng và application server có một luồng cho mỗi app và mỗi cửa sổ để không bị kẹt khi chờ app chậm phân tích message
      Vì vậy ngay cả một app BeOS tối thiểu có cửa sổ “Hello World” đồ họa cũng có 4 luồng. Dù app bận, phần còn lại của hệ thống vẫn cho cảm giác phản hồi tốt
      Đổi lại là chi phí throughput và độ phức tạp khi phát triển app, đặc biệt lớn với các app được port
      Haiku phải sắp xếp message của Qt/Gtk/toolkit từ nhiều cửa sổ vào một hàng đợi message duy nhất để tránh lỗi đa luồng. Vì trong môi trường gốc, vòng lặp message của app không đa luồng
      Do việc sắp xếp này, trên Haiku cần thêm các lệnh gọi khóa/mở khóa ngay cả khi không cần, chẳng hạn với các message đi tới cùng một cửa sổ
      Ngược lại, app native của Haiku thì mượt như băng. Đây là ảnh chụp màn hình trình biên tập video Medo, nơi mọi cửa sổ chạy trong luồng riêng: https://raw.githubusercontent.com/smallstepforman/Medo/refs/...
      Trên hệ thống hiện đại, app này mượt như băng, gần như dị biệt đối với một trình biên tập video. App Haiku được liên kết là do tôi viết
    • Tôi thật lòng mơ tới ngày máy tính hiện đại khởi động nhanh như Commodore 128 ngày xưa, reset cũng nhanh, và phản hồi nhanh nhạy với mọi phím bấm
    • Dù có dùng mẹo, nhưng vẫn phải ghi nhận là họ có cố gắng
      Tôi đã bỏ Android khi ngay cả Samsung cũng không thật sự nghiêm túc cải thiện độ phản hồi của điện thoại
      Việc Apple nhất quán coi trọng độ phản hồi là điều tốt, và nhờ vậy Google, Samsung, Microsoft cũng có động lực chỉnh lại những sản phẩm đã phình to của mình
    • Với tư cách người từng dùng BeOS và OS/2 Warp, tôi nhớ sự nhanh nhạy của các hệ thống cũ. QNX thì tôi chưa được trực tiếp thử
      Trong các hệ điều hành ngày nay, thứ nào gần với sự nhanh nhạy đó nhất? Có phải Haiku OS không?
      Tôi vẫn đang dùng tốt M1 MacBook, nhưng đôi khi cảm thấy vẫn chưa đủ
    • Tôi chưa từng chạy QNX, nhưng có trải nghiệm tương tự về việc Pentium 90 cho cảm giác rất tuyệt trên BeOS
      Một ví dụ khác là SGI IRIX, có bộ lập lịch tốt một cách khác thường. Tôi từng dùng một máy 30MHz trong một thời gian, và desktop khá nhanh nhạy
      Một hôm tôi biên dịch AMP rồi đưa vào danh sách MP3, phần lớn là 192kbps; nhân tiện, chương trình này cũng giải mã được 256kbps mà không giật
      Các file nằm trên một share NFS, và khi chạy gr_osview thì CPU dùng 95%, vậy mà trình quản lý file vẫn phản hồi và nhạc không hề bị ngắt
      Chỉ riêng việc giải mã MP3 bitrate cao hơn 192kbps trên 30MHz đã ấn tượng rồi
      Việc vẫn giữ được độ phản hồi trong khi chạy cả desktop X Window System và phát file từ share NFS cho thấy network stack và bộ lập lịch vừa nhẹ vừa mạnh, hoạt động tốt cả trên phần cứng cấu hình thấp
      Đó là IRIX 5.3, Indigo Elan
      Tôi và một người bạn thích hệ điều hành nên đã chạy BeOS trên chiếc Pentium 90 cũ, và như đã nói ở trên, nó rất nhanh nhạy
      Linux cũng góp một phần. Sau khi bị hư hại do nước, chiếc Pentium 90 đó không còn ổn định nữa, và vì dùng RAM không parity nên Windows NT dần trở nên kỳ lạ rồi liên tục màn hình xanh
      Cho vui, tôi cài Red Hat 5.2 lên thì nó chạy tốt. Log hệ thống ghi rất nhiều mục mỗi giây, và tôi có thể mở X console để chỉ nhìn chúng trôi qua
      Chiếc máy đó còn phục vụ trang web công ty trong vài tuần cho vui. Những ngày tháng đẹp đẽ
  • Bổ sung chi tiết thì mã nguồn QNX từng có thể truy cập từ năm 2007 cho đến trước khi RIM/Blackberry mua lại vào năm 2010
    Sắp tới có kế hoạch cung cấp lại quyền truy cập mã nguồn QNX không?
    https://www.qnx.com/news/pr_2471_1.html

    • Xin đừng bắt tôi cam kết lịch trình, nhưng rõ ràng chúng tôi đang đi theo hướng cởi mở và minh bạch hơn
      Chúng tôi nghe nói rằng điều này quan trọng với cả khách hàng lẫn cộng đồng. Hãy tiếp tục theo dõi
  • Công ty trước đây của tôi từng làm router Active/Standby độ sẵn sàng cao cho mạng di động, và dùng QNX làm hệ điều hành. Năng lực đó đến giờ vẫn còn ấn tượng
    Ký ức hơi mờ, nhưng chúng tôi chạy QNX trên bộ xử lý mặt phẳng điều khiển, và nó hỗ trợ native việc khởi chạy tiến trình trên bộ xử lý từ xa thông qua mạng nội bộ của router
    Tức là giao tiếp liên tiến trình cấp thấp có thể dùng IP, và IPC của QNX là phần thiết yếu cho chức năng failover độ sẵn sàng cao
    Việc driver thiết bị là tiến trình trong user space nên có thể khởi động lại khi bị crash cũng rất tuyệt. Tôi đang phát triển driver mạng nên thỉnh thoảng chuyện đó thực sự xảy ra
    Khác với Linux, nơi thiết bị mạng là ngoại lệ và không thực sự xuất hiện đúng trong cây /dev/, việc thiết bị thật sự hiện trong cây /dev/ cũng tốt hơn
    Một giai thoại thú vị là có lần xảy ra vấn đề vì tôi lỡ thêm const vào giá trị trả về của IPC, khiến tiến trình của tôi chết ở khoảng giữa hàm IPC của QNX và hàm của tôi
    Tôi đã debug nhiều ngày, và với trình debug C/user space dùng lúc đó thì không bắt được lỗi ấy

    • Tôi cũng từng làm với router cho mạng di động, nhưng mọi thứ đều chạy trên Linux, và mặt phẳng điều khiển cũng là Linux
      Các line card cũng là Linux, nhưng chỉ làm việc lập trình ASIC theo chỉ thị của mặt phẳng điều khiển
      Những tính năng kiểu đó không liên quan lắm, còn IPC thì có thể làm bằng HTTP hay bất cứ cách nào bạn muốn
    • Việc khởi chạy tiến trình trên bộ xử lý từ xa qua mạng nội bộ thì đã có thể làm với CP/NET(https://en.wikipedia.org/wiki/MP/M#CP/NET) hoặc CP/J chạy trên JUNET([https://pl.wikipedia.org/wiki/JUNET_(CP/J))
  • @JohnAtQNX có thể bỏ hạn chế tất cả đều cần tài khoản khi tải xuống từ website, và cũng loại bỏ cơ chế license của qcc không?
    Điều đó sẽ giúp rất nhiều trong việc khuyến khích developer làm vì sở thích thử nghiệm
    Doanh thu có lẽ đến từ các hợp đồng license số lượng lớn, theo mô hình thu phí license trên mỗi thiết bị đầu cuối
    Nếu làm các đội CI/CD phải hỗ trợ dòng sản phẩm QNX nổi giận, nguồn doanh thu đó sẽ gặp rủi ro

    • Chúng tôi đã từng thảo luận nội bộ về cách biến việc đó thành khả thi
      Thật tốt khi nghe cùng câu chuyện từ bên ngoài, và tôi sẽ đưa lại lên bàn để thúc đẩy dần dần
    • Ít nhất cũng nên cho phép đăng nhập bằng các dịch vụ khác như Google. Rất nhiều site đã làm vậy
      Tôi thật sự ghét việc cứ mỗi khi có thứ gì mới lại phải thêm một đăng nhập mới
      News feed cũng tương tự: gần như một nửa các trang tin nói là “miễn phí” nhưng vẫn yêu cầu đăng nhập. Trong trường hợp đó thì còn đỡ vì thường dễ tìm cùng bài viết ở nơi khác
    • Đúng vậy. Khả năng cao là người ta sẽ chuyển sang nơi khác ít ma sát hơn
  • Tôi vẫn còn nhớ mình đã kinh ngạc trước bản demo QNX trên một đĩa mềm duy nhất có cả trình duyệt web. Nó thật sự rất nhanh
    Hy vọng mọi chuyện suôn sẻ. Chỉ có thể tưởng tượng việc tháo gỡ hết các vấn đề pháp lý để thực sự mở thứ gì đó ra sẽ là một nút thắt Gordius khó đến mức nào
    Như những người khác đã nói, sau hai lần bị chơi xấu thì ai cũng thận trọng, nhưng QNX có nhiều điểm đáng thích, nên hy vọng lần này sẽ có được đà tiến

    • Đĩa mềm demo QNX đó vào cuối thập niên 90 đúng là như phép màu. Nó cho thấy trên CPU 486 DX2 hay DX4, mọi thứ có thể cho cảm giác nhanh đến mức nào so với Linux/Windows thời đó
      Từ đó về sau tôi vẫn có ấn tượng khá tích cực với QNX, nhưng những thay đổi quyền sở hữu và trạng thái mở/thương mại ở giữa luôn khiến tôi giữ khoảng cách
      Đáng tiếc là lần “mở” này cũng cho cảm giác quen thuộc, và tôi nghĩ nó sẽ lại bị rút lại trừ khi xuất hiện một cộng đồng tự do/mã nguồn mở đủ lớn với giấy phép GPL thực sự mở và đủ tự do để duy trì fork
  • Tôi thích thử nghiệm táo bạo này. Từ lâu tôi đã quan sát QNX với sự hứng thú ở bên lề, nhưng trong hầu hết trường hợp tôi không phải người dùng tiềm năng
    Bước tiếp theo hay sẽ là chọn một kiểu dự án sở thích phổ biến và viết một loạt bài blog giải thích trong bối cảnh đó có thể áp dụng điểm mạnh của QNX như thế nào

    • Tôi cũng muốn đọc những bài như vậy. Tôi tò mò về QNX, nhưng với tư cách một người mày mò robot ở nhà, tôi chưa hình dung được nó có lợi gì cho mình
      Tôi cũng làm cho một tổ chức phi lợi nhuận nghiên cứu giám sát bờ biển, nơi có vài người chế tạo phần cứng tùy chỉnh. Liệu nó có thể giúp ích cho chúng tôi không?
  • Rizin của chúng tôi muốn cải thiện hỗ trợ QNX cho framework dịch ngược và debug tự do/mã nguồn mở
    Hiện đã có hỗ trợ[1][2][3][4], nhưng chúng tôi không thể kiểm thử ổn định
    Sẽ rất tốt nếu có sẵn image QEMU mặc định, giống như Windows cung cấp ngay VM giới hạn để kiểm thử[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...

    • Với license QNX Everywhere miễn phí, bạn có thể khởi chạy QEMU VM từ IDE chỉ bằng vài cú nhấp chuột
      Tuy vậy tôi hiểu rằng nếu có thể tải xuống bằng một cú nhấp như image Windows thì sẽ dễ hơn, và tôi sẽ ghi nhận phản hồi đó
      Nếu chúng tôi có thể hỗ trợ theo cách khác để giúp khả năng hỗ trợ QNX thành hiện thực, hãy DM hoặc nhắn tới qnxcommunityengagement at qnx dot com