[HN Gopher] QNX is now free for anything non-commercial, plus th...
___________________________________________________________________
QNX is now free for anything non-commercial, plus there's an RPi
image
Hiya folks! I'm John from the Developer Relations team at QNX. I'm
a loooong time lurker of this forum and excited to make my first
post. I just wanted to let you know that we've kicked off a new
program to start opening the doors to QNX like things used to be.
Many of you probably used or tinkered with (the very open) QNX back
in the day. You can now easily get a free non-commercial license to
use the newest QNX. We've also just released some sample apps and a
ready-to-go QNX 8.0 quick start target image for Raspberry Pi. So
you can get QNX and the development tools for free now to learn,
experiment, and build. It's been a long time in the making, so I'm
really excited to get to post about this first phase of the QNX
Everywhere initiative. My team and management have open ears, so
please share feedback about what more we can do to open things up,
be more transparent, and get you what you need to create an awesome
embedded QNX project. Cheers!
Author : JohnAtQNX
Score : 344 points
Date : 2024-11-07 18:35 UTC (4 hours ago)
(HTM) web link (blackberry.qnx.com)
(TXT) w3m dump (blackberry.qnx.com)
| johndoe0815 wrote:
| To add some details - the source code for QNX was available from
| 2007 until the takeover by RIM/Blackberry in 2010.
|
| So do you plan to offer access to QNX source code again in the
| future?
|
| https://www.qnx.com/news/pr_2471_1.html
| JohnAtQNX wrote:
| Don't hold me to timelines, but we're definitely headed in the
| direction of being more open and transparent. We're hearing
| that this is important to our customers and the community
| alike. Stay tuned!
| f1shy wrote:
| But then it will be clear that almost nothing was done in
| that time...
| nisten wrote:
| The stock is almost dead. Please just opensource it instead
| of taking all that to the grave with you. Just do it.
| Animats wrote:
| I just looked. BB peaked around US$140 and is now around
| US$2. Financials are so bad it's amazing the doors are
| still open.[1]
|
| QNX is a great technology, but nobody who acquired it knew
| what to do with it.
|
| [1] https://www.bing.com/entitydetails?q=BB+stock&wt=Financ
| eGene...
| balou23 wrote:
| So from what I gather, this is the third time you want to be
| open and transparent with your sources?
| Onavo wrote:
| You are not John "patent troll" Chen right? Your ceo suck
| serf wrote:
| he retired last year, but it's amusing to think of some
| exec-level ceo going onto forums to peddle merch.
|
| with BB's stock performance : maybe?
| java-man wrote:
| This is a good move!
|
| In my opinion, any platform should be available for free for any
| non-commercial purpose. This is how people get started, and this
| is how the platform proliferates.
|
| I might even suggest going a bit further: provide some limited
| support for non-commercial users, for example, make it super-easy
| to file a bug.
|
| But otherwise, it's a win-win for both the free tier (students,
| hobbyists) and the corporate.
| JohnAtQNX wrote:
| This is great feedback, thanks! I absolutely want to find ways
| to provide some support -- a bug portal is a fantastic idea.
| For now we're accepting issue reports though gitlab.com/qnx.
| VoxPelli wrote:
| Eg the Business Source License and the Functional Source
| License makes it always available for non-commercial use
| tlack wrote:
| Kudos on your bold undertaking! I've been a side-lined QNX
| admirer for some time, though not a potential user in most cases.
| A good next step would be a series of blog posts where the author
| takes on common types of enthusiast projects and unpacks how
| QNX's strengths can be applied in those scenarios.
| steve_adams_86 wrote:
| I'd love to see this. I'm curious about QNX but at a loss as to
| how it could benefit me as someone who tinkers with robotics at
| home.
|
| I also work for a non-profit org which does coastal margin
| research. We have several people working on custom hardware.
| Could this benefit us?
| bregma wrote:
| Start with https://gitlab.com/elahav/qnx-rpi-
| book/-/blob/master/pdf/qnx... as an intro to tinkering at
| home.
| throw0101a wrote:
| Does it come on a 1.44MB floppy (image)?
|
| * http://toastytech.com/guis/qnxdemo.html
|
| * https://winworldpc.com/product/qnx/144mb-demo
|
| * https://crackberry.com/heres-how-qnx-looked-1999-running-144...
| ilhuadjkv wrote:
| Wait, http://127.1/
|
| In the browser in the crackberry video
|
| what the....
| Jtsummers wrote:
| 127.1 is the same as 127.0.0.1. 0 bytes are inserted based on
| the following: x -> 0.0.0.x x.y
| -> x.0.0.y x.y.z -> x.y.0.z
| bryanlarsen wrote:
| But sometimes 127.1 means 127.1.0.0/16. For example in the
| output of `netstat -rn` on MacOS.
| Jtsummers wrote:
| Good to know.
|
| I was also coming back in to edit my comment and write
| that my x -> 0.0.0.x was technically wrong and the same
| for the others. If you stick to only single-byte values
| then what I wrote was correct but if the values span
| multiple bytes they fill in the missing 0s appropriately,
| as in: 256 -> 0.0.1.0 1.256 ->
| 1.0.1.0
| elcritch wrote:
| Similar rules apply to ipv6 addresses as well.
| jandrese wrote:
| IPv6 at least sensibly has a different delimiter for when
| you are eliding zeros.
| moefh wrote:
| It's not really about eliding zeros, though. It's kind of
| a cursed thing: x -> x3.x2.x1.x0
| x.y -> x.y2.y1.y0 x.y.z -> x. y.z1.z0
| x.y.z.w -> x. y. z. w
|
| Where x0 is the 8 least significant bits of x, x1 is the
| next 8 higher bits, and so on.
|
| The "zeros" happen when the last number is smaller than
| 256 (or 65536, etc.), but it doesn't have to be. For
| example 10.258 is a valid way to write an IPv4 address,
| it's the same as 10.0.1.2.
| inChargeOfIT wrote:
| little known fact: you can write shorthand for any ip
| address. It simply omits 0. Ie 127.0.0.1 (or
| 127.000.000.001). Try pinging it. `ping 127.1`
|
| 10.0.0.3 -> ping 10.3
| simlevesque wrote:
| what's the problem, there's a self hosted web server on it.
|
| If you are talking about the short url, well ipv4 allows it
| and they needed to save space to fit on the floppy ;)
| deathanatos wrote:
| It's a particularly cursed form of writing IPv4 addresses:
|
| > _A popular implementation of IP networking, originating in
| 4.2BSD, contains a function inet_aton() for converting IP
| addresses in character string representation to internal
| binary storage. In addition to the basic four-decimals format
| and 32-bit numbers, it also supported intermediate syntax
| forms of octet.24bits (e.g. 10.1234567; for Class A
| addresses) and octet.octet.16bits (e.g. 172.16.12345; for
| Class B addresses). It also allowed the numbers to be written
| in hexadecimal and octal representations, by prefixing them
| with 0x and 0, respectively. These features continue to be
| supported in some software, even though they are considered
| as non-standard._
|
| (https://en.wikipedia.org/wiki/Dot-
| decimal_notation#IPv4_addr...)
|
| Never use this.
| JohnAtQNX wrote:
| Not this time! =). But today's floppy equivalent is a micro-SD
| card.. Right? Right?
| altairprime wrote:
| For QNX 8.0, here's a saved-you-five-minutes direct link to the
| developer terms associated with noncommercial use:
|
| https://support7.qnx.com/download/download/51624/BB_QNX_Deve...
|
| _(I am not your lawyer, this is not legal advice. This is not a
| comprehensive review, assessment, or summary of possible
| interpretations of that license. Seek professional counsel from a
| lawyer before acting on anything stated below.)_
|
| These terms open with a 'user did not have an opportunity to
| review and agree before binding themselves, their business,
| and/or their institution' clause that may well wholly invalidate
| the entire document in the US, so please review these with your
| lawyer before use, so that your usage is not put at risk due to
| legalese overreach.
|
| Academics, only students and faculty of _your_ institution
| qualify, and your usage under this license will be viewed by your
| legal team as you signing a binding agreement on behalf of your
| employer; make sure you're not exposed to liability through open
| source contributors or at risk of being fired for misrepresenting
| yourself as a signing authority for your institution.
|
| Cloud users, your license is restricted to AWS per their terms;
| use on GCP, Heroku, or any other server instance not under your
| personal contractual control may result in owing licensing fees.
|
| Only OSI definitions of "Open Source" are permissible here; this
| disqualifies anyone licensing software under a restrictive non-
| commercial license from making use of the QNX non-commercial
| license, as per OSI, _all_ such restrictions are not "open
| source".
|
| Social apps are excluded by the "high risk" clause, which
| prohibits any use under these terms to develop applications that
| could harm society. Take care not to create viral applications
| that violate this clause.
|
| They collect and retain all serial numbers identifiable on all
| hardware you use in association with this product.
|
| Your noncommercial license may be severed unconditionally at any
| time without recourse, regardless of whether you have faithfully
| complied with the terms; at which time you may be compelled under
| contract to provide an undefined 'certification' of indeterminate
| cost that you deleted all QNX code provided to you.
|
| Stay safe, folks.
| mech422 wrote:
| Will Photon be available as well ?
| 0x457 wrote:
| This isn't an OS meant for desktops.
| bigfatkitten wrote:
| There are many uses for graphical UIs outside general purpose
| desktops.
| speed_spread wrote:
| It used to be desktop-friendly enough to develop on. It's not
| a purely embedded OS.
| CyberDildonics wrote:
| Reinventing QNX will always be seen as cutting edge.
| peppertree wrote:
| 20 years too late but ok.
| ok123456 wrote:
| And about a month after the RT Linux patches were put in the
| kernel master.
| Joel_Mckay wrote:
| Agreed, a walled garden is still a walled garden...
|
| Even a $12 SoC is no longer resource constrained with a
| stripped minimal Linux kernel. QNX missed their launch window
| decades ago...
| f1shy wrote:
| The just bought a cow and wanted to milk to death. RIM is
| just a slow company to react.
| foolswisdom wrote:
| For anyone who (like me) was confused at what this is, it's a
| Unix like OS for embedded systems.
|
| https://en.m.wikipedia.org/wiki/QNX
| simlevesque wrote:
| They are the brains of a ton of cars on the market, like all
| Ford cars. Used for complex calculations like automatic
| transmissions.
| JohnAtQNX wrote:
| I think we're at something like 235 millions cars on the road
| today with QNX inside. The volume blows my mind. We're also
| hiding inside lots of healthcare products, industrial control
| systems, etc.
|
| There's lots of interesting key differences between something
| based on Linux, for example, and QNX. Worth digging into if
| you're interested in these things. My colleague wrote a short
| ebook and the intro has a good summary:
| https://gitlab.com/elahav/qnx-rpi-book/-/tree/master/pdf
| WillAdams wrote:
| There is however also TRON:
|
| https://ethw.org/Milestones:TRON_Real-
| time_Operating_System_...
|
| which was demoed running on an 80186 with _multiple_
| windows running videos w/o dropping a frame.
|
| Described as "The most installed operating system in the
| world":
|
| https://www.linuxinsider.com/story/the-most-popular-
| operatin...
|
| Unfortunately, the U.S. State Department viewed the
| Japanese plan to place it on all computers in their
| educational system as anti-competitive.
|
| Really wish it was available for the Raspberry Pi.
| criddell wrote:
| QNX was the OS behind the ICON computer that was used in
| schools across Ontario in the mid-80's. At the time, I
| thought they were pretty cool.
|
| https://en.wikipedia.org/wiki/ICON_(microcomputer)
| JohnAtQNX wrote:
| Wow, I didn't know this! Thanks for sharing!
| justin66 wrote:
| Wow. 80186. That's something you don't see every day.
| wwweston wrote:
| I think my (American) HS had two of these just a few years
| later, but I didn't remember any QNX connection!
| wolrah wrote:
| > They are the brains of a ton of cars on the market, like
| all Ford cars. Used for complex calculations like automatic
| transmissions.
|
| I would seriously doubt that QNX or anything like it
| resembling a "real OS" is running on the automatic
| transmission. If the transmission controller is running any
| OS at all it's likely a microcontroller running a much more
| specialized RTOS.
|
| QNX is very common in automotive applications, but in things
| like digital instrument clusters and ADAS where the software
| is complex enough to benefit from a full networkable OS with
| support for a lot of different high speed buses but the use
| case still needs real-time guarantees and/or microkernel
| stability. I've specifically seen QNX's hypervisor marketed
| for digital clusters where the critical data display and
| interaction with the ECU could happen within a fully
| certified QNX environment that would be designed to be as
| stable and reliable as possible while allowing infotainment
| applications to run in a VM instance of Android, Linux, or
| even more QNX where software reliability was less critical.
| If it crashes, the important instruments are still working.
|
| Ford's "Sync 3" and "Sync 4/4A" infotainment systems run on
| QNX as well, though being just infotainment they didn't
| really care about the realtime aspect (though I'm sure
| stability was a big thing compared to their Windows CE based
| predecessors). They've moved to Android for their latest
| revision.
| toast0 wrote:
| > Ford's "Sync 3" and "Sync 4/4A" infotainment systems run
| on QNX as well, though being just infotainment they didn't
| really care about the realtime aspect (though I'm sure
| stability was a big thing compared to their Windows CE
| based predecessors).
|
| I've got a Sync 2 car, and I can't say I've noticed
| instability. The UI toolkit is _slow_ , but the story on
| that is someone's cousin did something some Macromedia
| stuff that barely worked and they shipped that. I've got
| some issues with GPS offset, but that's pretty stable. I
| had worse stability with the Chrysler UConnect in my 2017
| Pacifica, and that was reportedly based on QNX; it would
| sometimes crash and restart, or the screen would not come
| on at all unless you knew the magic buttons to hold to
| force reboot.
| Geee wrote:
| Does this mean it's good or bad? These companies aren't
| exactly the beacons of innovation.
| altairprime wrote:
| Subaru runs WinCE, or still did ten years ago anyways.
| Hopefully they cutover to something else someday!
| steve_adams_86 wrote:
| What would be a good hobbyist project to learn QNX?
| f1shy wrote:
| None, I guess. It is just a Posix OS, with not the brightest
| future.
| 0x457 wrote:
| Maybe not the brightest future, but it's more than just a
| POSIX OS.
| JohnAtQNX wrote:
| We have a couple of students working on bringing up the
| hardware in the Pimoroni Trilobot kit on QNX, but adding some
| ML to the camera for some kind of autonomous steering perhaps.
| It will be the perfect blend of intensive processing
| (camera+ML) with hardware control (short high-priority
| interrupts). (P.S. hope to open-source this when they are done,
| along with some blog posts or tutorials -- stay tuned.)
|
| Separately, I think making a GPS-synced weather station would
| be a fun project. QNX is often used when tight timing is needed
| for telemetry, so using it to collect weather (and other) data,
| including from pulsing hardware like an anemometer, and then
| publishing it to an online service would be a lot of fun.
|
| If software-only is more your style, there may or may not be
| someone in the office next to me porting some classic games
| right now! =)
| hawski wrote:
| I would like to explore it's IPC. I heard a lot of good about
| it. For example that it is has quite a nice API and is
| efficient.
|
| Maybe I will tell it all wrong, but I remember that for example
| it could be easy to do RPC on the same machine for the
| isolation. A client calls the server and the scheduler would
| switch context immediately to the server process upon IPC.
| masijo wrote:
| I need to know if it comes with Photon microGUI! Please, lord,
| let it happen...
| wmf wrote:
| Photon was dropped years ago. They use a completely new
| graphics architecture now.
| AceJohnny2 wrote:
| My previous company, which made high-availability
| (Active/Standby) routers for mobile networks, used QNX as the OS.
| I remain impressed by its capabilities.
|
| My memory is rusty, but we ran QNX on the control-plane
| processors, and it natively allowed launching processes on remote
| processors over the internal network of the router. That is:
| their low-level IPC was IP-capable. QNX's IPC was essential for
| our HA failover functionality.
|
| Also, device drivers as user-space processes that you could
| restart on crash was great (we were developing our network
| drivers, so this would occasionally happen). Also, better respect
| for devices actually showing up in the /dev/ tree, unlike Linux
| where network devices are a notable exception.
|
| One funny story, I once spent days debugging an issue which
| turned out to be due to me accidentally marking const the return
| values of some IPC, which caused my process to crash in between
| QNX's IPC function and mine! Whatever level of debugger
| (C/userspace) I was using at the time could not catch the error
| ^^;
| MichaelZuo wrote:
| For attracting more developers can you compile a comarison table
| with the benefits of QNX versus competitors?
|
| The existing information out there is of questionable reliability
| and probably out of date too...
| JohnAtQNX wrote:
| This is a good blog post idea. I'll get it on our backlog.
| jsheard wrote:
| TIL the Blackberry brand still exists in this space. Similar to
| Nokia I suppose, the consumer side no longer exists but the
| enterprise side is still going.
| baq wrote:
| I don't want to create an account just to know if it'll work on a
| pi zero w, will it?
| JohnAtQNX wrote:
| Right now, in the Pi family, only the Pi 4 on the BCM2711.
| Jtsummers wrote:
| https://blackberry.qnx.com/en/developers/board-support-packa...
| - no need to create an account, BSPs listed here and you can
| filter by several fields.
| myself248 wrote:
| As I was scrolling down, I saw all the TI Jacinto and Sitara
| dev boards, and I wondered if there might be one for the
| Beaglebone. And indeed, scroll a bit further!
|
| That's convenient, as I have a lot more of those sitting
| around than I do Pis at the moment.
| SushiHippie wrote:
| My experience looking at the page as someone who has never heard
| of QNX:
|
| First there is so much text that wants to tell me how great this
| software/tooling/resources is, without telling me what exactly it
| is.
|
| As I still wanted to know what it is, after reading your comment
| here+, I clicked on the front page https://blackberry.qnx.com/en
| which has a concise introduction
|
| "Real-Time OS and Software for Embedded Systems
|
| Launch your critical embedded systems faster with our commercial
| RTOS, hypervisor, development tools and services."
|
| An RTOS for embedded system, aha! That would be valuable
| information on the QNX Everywhere page. (Real-Time OS / RTOS
| isn't mentioned once)
|
| Then I found the resources section nearly at the bottom, which
| has quick start guide, where I can see what I will get when I
| sign up for a free license and that would be exactly what I (as
| someone who has no clue what to expect from QNX) would want to
| see at the top, after a short introduction to what it is and why
| I want to try it out.
|
| Maybe this page is more intended for people who are already aware
| of QNX, but if you intend to "catch" new people I really would
| recommend you to reorder/simplify this page, by putting relevant
| information (like a short introduction, why I would want to try
| it and a quick start guide) at the top instead of a wall of
| marketing text.
|
| + this comment was first under a comment from the author, which
| now got moved to the HN post text
| f1shy wrote:
| Bad product, bad company, bad marketing. Consistent.
| AlotOfReading wrote:
| You'd be one of the first people I've seen that doesn't like
| QNX itself. Normally people complain about the licensing or
| RIM. What issues do you have?
| armaautomotive wrote:
| This is very interesting and I'm happy to see this. It's probably
| not relevant but i'm remembering reaching out 20+ years ago for a
| license to use in a Darpa GC team and getting a quote for 16K
| which made it unavailable for our make shift team but I have a
| tremendous amount of respect for the company and their work to
| build QNX. I will probably be looking into this for something in
| the future.
| farseer wrote:
| With linux options in embedded space aplenty, who would want to
| move to a propriety os? QNX's big brother Vxworks has already
| been pushed out of most consumer embedded devices and is now
| limited to space probes and critical medical equipment. I just
| don't see a future for QNX anywhere.
| NexRebular wrote:
| Not everything has to be linux. It's good to have options for
| avoiding monoculturalization.
| eikenberry wrote:
| It's not a real option (to Linux) though at it is still
| governed by a non-free license.
| elcritch wrote:
| Dealing with Linux can be a PITA. Once you get a base system up
| you still need to roll a bunch of our own stuff. Do you use
| System unit or systemd, etc. The driver api's are pretty
| unstable.
|
| I make embedded linux device and I'm curious if QNX could make
| things easier, especially for long term stability.
| mcflubbins wrote:
| There's BSD too (e.g. Playstation, Apple Airport, Some POS
| devices and printers)
| smarx007 wrote:
| For real-time systems, QNX should be compared to FreeRTOS,
| CMSIS/RTX, VxWorks, or, if you after the new cool stuff,
| Zephyr, perhaps, but not Linux.
| beardyw wrote:
| > Many of you probably used or tinkered with (the very open) QNX
| back in the day.
|
| Well I didn't and it was not easy to understand what it is from
| your website. Wikipedia came to my rescue. You may want to
| consider that.
| j1mmie wrote:
| I'm interested in building a Unity game for Raspberry Pi 4. Does
| QNX have good graphics support for RPi currently?
| JohnAtQNX wrote:
| That's awesome! It's decent, yes. The starter image comes with
| a graphical app launcher you can check out. I'll poke the team
| about releasing the source for that launcher soon (I think they
| wanted to clean it up so it's a good sample).
| Animats wrote:
| If only you could believe them.
|
| QNX has been "opened" twice before. Each time, there was a rug
| pull, and it went closed again.
|
| Before the first rug pull, open source groups routinely added QNX
| to their target list. There was a Firefox for QNX. Eclipse had
| QNX as a target. GCC and most of the Gnu command line tools could
| be built for QNX. There was a desktop environment, Photon. I used
| that as a primary desktop for three years when working on a DARPA
| Grand Challenge vehicle.
|
| All of that went away after the Harman acquisition of QNX in
| 2004.
|
| Then, in 2007, QNX went open source. You could even look at the
| microkernel. It wasn't openly licensed, but you could look inside
| and build it.
|
| In 2010, RIM acquired QNX, and, with no warning, closed the
| source. All open source development related to QNX ceased, and
| QNX lost all credibility in the community. So QNX shot itself in
| the foot. Twice.
|
| Note the contractual terms.[1] "TERMINATION. This Agreement and
| licenses granted hereunder may be terminated by either Party upon
| written notice to the other Party". QNX can pull the plug at any
| time. Since they've done so twice in the past, there's a good
| chance that will happen again.
|
| Now, if QNX is serious about this, the way to go is to use the
| licensing model Epic uses for Unreal Engine. Unreal Engine is
| behind most AAA game titles. The basic terms are that you can
| download the source and use it for anything you want, and there's
| no charge until you get the first $1 million in revenue from your
| product. Then Epic takes a 5% royalty.[2] This has been extremely
| successful for Epic. There's not much of a piracy problem,
| because if your game gets enough revenue to matter, it has enough
| visibility that their licensing people will notice. Meanwhile,
| there's a large pool of people using Unreal Engine.
|
| That's the way to do it if you want more adoption of QNX. Take
| the Epic term sheet to your lawyers and management. And have them
| take a look at Unreal Engine's revenue growth vs. QNX.
|
| As I once told a QNX sales rep, your problem isn't that you're
| being pirated. It's that you're being ignored.
|
| [1] http://www.qnx.com/download/feature.html?programid=51624
|
| [2]
| https://cdn2.unrealengine.com/UnrealEngine/faq/UnrealEngineE...
| Tomte wrote:
| For everyone else, your QNX comment from 2015:
| https://news.ycombinator.com/item?id=9872640
| stevesimmons wrote:
| As someone who knows only that QNX is a RTOS and that "real
| time" is good in some vague hand-wavy way, I found this 2015
| comment a very succinct, concrete and illuminating
| description of one aspect of QNX's architecture that makes it
| properly real-time.
|
| So thank you very much for the link.
| mwcampbell wrote:
| > Somebody really should write a microkernel like this in
| Rust.
|
| I wonder how far Redox's microkernel design is from what that
| comment describes.
| stackghost wrote:
| Shitty dx is baked into RIM/Blackberry's institutional DNA.
|
| I had a long conversation with their engineering people way
| back before BB10 came out. At the time you had to apply to get
| access to the full blackberry SDK, and IIRC you also had to
| sign an NDA. Meanwhile Android and iOS were in full swing and
| wouldn't you know it, the platforms that had better developer
| experience, that prioritized making it easy to write apps, were
| successful.
|
| Blackberry is just institutionally incapable of handling this
| sort of relationship with the community. It's that legacy telco
| "us vs them" mindset at the top of the org, and it filters down
| whether implicitly or explicitly.
| baby_souffle wrote:
| It was worse than an NDA! You also had to start your
| application with a trip to a notary to get your ID confirmed.
|
| And if their signing servers were down...You couldn't load
| had just compiled onto your own dev / test device.
|
| I loved using my blackberry but I hated developing against
| it. Bb10 was its own little adventure but had similar
| draconian dx
| yjftsjthsd-h wrote:
| > Now, if QNX is serious about this, the way to go is to use
| the licensing model Epic uses for Unreal Engine. Unreal Engine
| is behind most AAA game titles. The basic terms are that you
| can download the source and use it for anything you want, and
| there's no charge until you get the first $1 million in revenue
| from your product. Then Epic takes a 5% royalty.[2] This has
| been extremely successful for Epic. There's not much of a
| piracy problem, because if your game gets enough revenue to
| matter, it has enough visibility that their licensing people
| will notice. Meanwhile, there's a large pool of people using
| Unreal Engine.
|
| One option: Dual-license as GPLv3 (the 3 is important!) or
| commercial license. Hobbyists and FOSS projects will be quite
| happy to use a GPLv3 OS. The big commercial users -
| traditionally cars and other embedded uses - will not want to
| be legally obligated to give users the ability to install
| custom firmware (which GPLv3 basically requires), so they'll
| still pay for it. Everyone wins.
|
| (IANAL, this is not legal advice, interpret licenses yourself.)
| dystnitem4r3 wrote:
| Even more critically, dual-license commercial and AGPLv3 to
| avoid the AWS loophole (hosted services or source
| modifications without licensing it commercial.)
|
| AGPLv3 is perfect for kernel and userspace tools because,
| while it doesn't guarantee licensing revenues, as soon as
| they do anything to modify it they have to release those
| changes to _ANY_ users of the system, whether downstream
| distributors or simply users of the network services they
| provide. Since they have to provide any IP /patents they used
| to do it under copyleft terms, QNX would get publicly visible
| benefits, albeit with changes that might not be useful under
| the commercial license without negotiating a CLA with the
| modifying party, but under the commercial license you could
| negotiate terms/a discount to trade their new code for a
| reduction in their cost of licensing. It's a win/win from
| either an open source PR or a behind the scenes commercial
| negotiation point. Obviously your lawyers, bean counters, and
| C-suite have to get onboard, but if you are serious about
| growing QNX's marketshare now that Linux is gaining real-time
| kernel support in mainline, you had better point out to your
| bosses they need to make the decision quick and stick to it,
| or there won't be a next time.
|
| Edit: Adjustments made to clarify my position and suggestion.
| apitman wrote:
| Even getting the licensing right isn't sufficient. They could
| license it as MIT today, close source it again tomorrow, and
| within a few releases no one would be using the MIT version.
|
| Unless someone is interested in maintaining a full fork. It's
| the same reason Google can do whatever they want with Chromium
| even though it's technically open source. No one else has the
| resources/will to maintain it so there's no credible threat of
| a fork.
| justin66 wrote:
| That's not a great example. Maintaining a full fork of QNX
| would not be terribly complex compared to maintaining a full
| fork of Chromium. The latter targets standards which are
| moving and evolving. Nobody cares which version of POSIX QNX
| is compatible with. (Also, Chromium is much bigger)
|
| I think a fork could have some maintainers. I'd be more
| worried about people wanting to put new features in than
| anything else.
| PaulHoule wrote:
| Also I wonder how many applications really need more real time
| responsiveness than you can get out of Linux. We even have
|
| https://arstechnica.com/gadgets/2024/09/real-time-linux-is-o...
|
| If I use Linux I know I won't have to have a discussion about
| licensing, I know I won't get rug pulled, etc.
|
| Also the ban on commercial use is heinous. I am going through
| this with Arangodb right now. I love the product, but I have no
| budget for a cloud instance they manage and I have no budget to
| talk with their sales people about a commercial license. I have
| several systems that use it (including one that's about 80% of
| a way to a "too big for free" database) and I don't know if
| their fate will be (a) open sourcing, (b) a product or (c) a
| system that makes money for me directly but for me the short
| path is to switch to postgres, not talk to people whose
| business model doesn't necessarily allow my business model.
| sitzkrieg wrote:
| rt linux is not appropriate for many hard realtime
| requirements
|
| i have seen some try and fail in an effort to save
| $perceived_value
| eikenberry wrote:
| Is there a good libre real-time OS you would recommend over
| it?
| serf wrote:
| chibios is great, but I haven't followed their culture or
| licensing in a few years now.
|
| my experiences then would lead me to recommend it,
| though.
| MisterTea wrote:
| RTEMS is one and there is also eCOS. RTEMS has flown in
| space a few times so it is proven.
|
| Forgot to mention: the neat part of RTEMS is it allows
| one to sort of turn a Unix program into a bare metal
| program.
| RandomThoughts3 wrote:
| [delayed]
| cxr wrote:
| > Now, if QNX is serious about this, the way to go is to use
| the licensing model Epic uses for Unreal Engine.
|
| If they're serious about this, given their history, the way to
| go is to do things the way Linux and BSD do things. A
| mainstream OSI-approved license or GTFO.
| wakeupcall wrote:
| Back before 2004, QNX could have still been relevant as there
| was still a lot of OS experimentation from the user/developer
| themsevels. They could have attracted enough people to carve a
| niche even in the desktop space at that time.
|
| After beos failed, I played/developed with QNX until they
| pulled the rug. I was on it full time on my main dev machine. I
| loved it.
|
| When they closed it I got severely burned to the point that I
| will not touch a any closed development platform. I see from
| the license they didn't change a bit.
|
| Not that it matters anymore.. they're largely irrelevant today
| except for whatever existing markets they already have. It
| would be fooling to choose QNX today: we now have good
| alternatives, and all of them with open licenses.
| mikercampbell wrote:
| With all due respect, I've never spent so long clicking through a
| website trying to figure out what it actually was.
|
| What is QNX haha
| mikercampbell wrote:
| I mean, I figured it out from HN but still.
| Animats wrote:
| QNX is a microkernel-based real time operating system. The
| kernel is tiny; it was about 60KB (not MB) twenty years ago.
| All the kernel does is message passing, timers, CPU
| dispatching, and memory allocation. Everything else is in user
| space, including file systems.
|
| Everything is a message, rather than being a file. Messaging
| works like a function call - you send a block of data to
| another process, wait, and get a reply back. Processes which
| receive messages act like servers - they have a thread or
| threads waiting for incoming requests, and when a request comes
| in, it's handled and a reply is sent back. It's a microservices
| architecture.
|
| Unlike Linux, it's a _fast_ microservices architecture. Message
| passing and CPU dispatching are integrated. When a process
| sends a message to a service process, the sender blocks.
| (Timeouts are available.) If the service process isn 't busy,
| control immediately transfers to the service process without a
| trip through the CPU dispatcher. When the service process
| replies, the reverse happens, and control goes back to the
| original sender. With most inter-process communication systems,
| there's queuing delay for this kind of operation. QNX got this
| right. This is the core insight behind QNX.
|
| Yes, there is message passing copying overhead. In practice
| it's under 10%. I've sent video through the message system.
| Copying is less of a problem than you might expect, because,
| with today's large CPU caches, the data being copied is
| probably warm and in cache.
|
| All this is real-time aware. Higher priority processes get
| their messages through first. If you call a service, it
| inherits the caller's priority until it replies. This prevents
| priority inversion, where a high priority process calls a low
| priority one and gets preempted by lower priority work. This
| works so well that I was able to do compiles and web browsing
| on a single-CPU machine that was also running a robot vehicle.
|
| There's a tool for building boot images. You put in the kernel,
| a standard utility process called "proc", and whatever else you
| need available at startup. For deeply embedded systems, the
| application might go in the boot image. It's all read-only and
| can execute from ROM if needed, which is good for applications
| where you really, really want startup to always work.
|
| Files and file systems are optional. For systems with files,
| there are file system and disk drivers to put in the boot
| image. They run in user space. There's a standard startup
| program set that creates a Unix-type environment at boot time.
| This is all done in user space. The file system is accessed by
| message passing.
|
| System calls look like POSIX. Most of them are implemented in a
| library, not the kernel. Service processes do the work. When an
| application calls POSIX "read", the library makes an
| interprocess function call to the file system or network
| service server. Program loading ("exec") is done in user space.
| The boot image can contain .so files. "Exec" is done by a .so
| file that loads the image. So the kernel doesn't have to worry
| about executable format, and program loading is done by
| untrusted code.
|
| Because it uses POSIX, most command line UNIX and Linux
| programs will compile and run. That's QNX's big advantage over
| L4. L4 is a good microkernel, but it's so stripped down it's
| just a hypervisor. Typically, people run Linux on top of L4, so
| all the bloat comes back.
|
| There is no paging at the OS level. That would kill real-time.
| There's a paging to disk library that can be used by programs
| such as compilers with big transient memory needs, but most
| programs don't use it. The effect is that responsiveness is
| very consistent. I miss using QNX desktop. There's _no lag_.
|
| So that's an overview. Microkernel done right.
| Retr0id wrote:
| I was excited to see "free", and even more excited to read "like
| things used to be", but after reading more closely I see it's
| merely free-as-in-gratis, as opposed to the more interesting
| definitions.
| fauria wrote:
| In case you are wondering: _QNX is a commercial Unix-like real-
| time operating system owned by BlackBerry, aimed primarily at the
| embedded systems market._
|
| From https://www.sealevel.com/2023/01/02/what-is-qnx
| fulafel wrote:
| The "unix-like" characterisation seems it might be be from the
| Wikipedia QNX article and repeated by a lot of web content. But
| it doesn't seem really accurate to me and it's not used by
| their own web site or documentation. It seems quite opposite to
| Unix in a lot of ways even though it has some API
| compatibility.
| fauria wrote:
| You should update the Wikipedia article in that case.
| bitwize wrote:
| It's got a POSIX API layer, but it's about as "unix-like" as
| Haiku.
| bregma wrote:
| How does it seem like the opposite? It's POSIX.
| Lammy wrote:
| Perhaps Wikipedia by way of the old QNX FAQ? https://web.arch
| ive.org/web/20080424102623/https://www.bitct...
|
| "In the early 80's they began work on a small message passing
| kernel based OS that had some user interface similarities to
| UNIX."
|
| "They called their product QUNIX, reportedly because it was a
| "Quick UNIX". They named their company Quantum Software
| Systems Limited. The QUNIX name lasted a year or two until
| they received notice from AT&T; that a change would be
| appropriate. Always ready for a challenge, they changed the
| spelling to QNX(r) without changing the pronunciation."
| hacknews20 wrote:
| Great. Long over due, maybe too late.
| initramfs wrote:
| I found this a while back. Unsure if it's related
| https://github.com/vocho/openqnx
|
| (I prefer 32-bit because most applications don't need more than
| 4GB RAM, but I guess 64-bit could be useful too)
| bexsella wrote:
| I've had a lot of experience in developing on QNX over the years,
| and with each successive year, the call to migrate to Linux got
| stronger. The day to day developer experience is great, you can
| very easily setup a CMake toolchain and bypass the need for QNX's
| Momentics, which if you're just developing for QNX is something
| you will want to do. But, in my experience the driver support
| simply isn't there, and that became painful. A fair few major
| board manufacturers treat QNX integration as a complete
| afterthought, and at a point you start to feel that this is
| directly related to RIM's decision to shutdown source access to
| QNX. I've since left that company, but I imagine there is still a
| call to use Linux.
| bregma wrote:
| I use CMake for QNX all the time. It just works, out of the
| box.
| brynet wrote:
| I don't have great expectations for this, we've been rug pulled
| before.
|
| https://www.osnews.com/story/23565/qnx6-is-closed-source-onc...
|
| They then killed the self-hosted QNX entirely, no downloadable
| .ISOs after 6.5. No working toolchain, so porting software became
| difficult, pkgsrc abandoned.
|
| They are completely noncommittal, nothing short of actually open-
| sourcing it, MIT/BSD, would convince me otherwise.
| jauntywundrkind wrote:
| I wonder how much DBus (the Inter-Process-Communication (IPC)
| standard Linux desktops have been based around) is baked into QNX
| & instrumental to it! Maybe I can find out now?
|
| https://ioactive.com/pdfs/IOActive_Remote_Car_Hacking.pdf or
| https://insights.sei.cmu.edu/blog/vehicle-cybersecurity-the-...
|
| That was such a time. It's sad that it was a security panic, to
| me, because there was incredible promise there... All of the cars
| infotainment, windows, interior lighting, HVAC, all these things
| are just DBus services hosted on QNX? And I can just connect to
| my car & modify them, in some cases even over the air? QNX & DBus
| could have been a huge selling point, could have been such an
| awesome way to debundle the car from its infotainment. If only.
|
| Really interested to see if DBus really does underpin much of
| QNX, or whether this was just a time & place. Seeing how
| monolithic versus networked QNX is in general would be
| fascinating; is there one or two QNX hosts & lots of devices, or
| so the story more distributed that that?
| sriram_sun wrote:
| Is there an eBPF equivalent for QNX? Also, with the real-time
| linux patch (which has been mainlined now), I'm able to run C++
| ROS2 control loops @ 1ms down to even 250us on commodity off the
| shelf i3 and i5 hardware with dedicated cores.
|
| I've worked on vxWorks, QNX and Linux and I found the pace of
| development using Linux the fastest.
| craftkiller wrote:
| Wouldn't that not make sense for QNX? eBPF is for running code
| in kernel space but QNX is a microkernel. The microkernel
| approach would be to just run another userspace program like
| any other program.
| wkat4242 wrote:
| Oh cool, does this also include the unfortunately discontinued
| desktop version of QNX? I've always wanted to try out a real time
| OS
| eikenberry wrote:
| Why not real-time Linux? It's even been accepted into mainline
| now.
| wkat4242 wrote:
| Is that a true RTOS though? I thought it was only a partial
| implementation
| rw_grim wrote:
| > Develop open-source software (OSS) that is interoperable with
| QNX software, provided you make the resulting OSS publicly
| available at no charge.
|
| Even the GPL doesn't have this restriction...
| nrclark wrote:
| @JohnAtQNX can you remove the "everybody needs an account"
| restriction from your website downloads, and also remove the
| license mechanism from qcc? That would go a long way towards
| encouraging hobbyists to try it out.
|
| Your money comes from high-volume licensing deals, where you
| presumably get a per-unit license fee. That revenue stream is
| jeopardized by pissing off the CI/CD teams that have to support
| QNX product lines.
| JohnAtQNX wrote:
| Hiya! We've discussed how to make that work. It's good to hear
| the same thing from an outside voice. I'll bring it back to the
| table to inch it along. Thanks!
| ksaj wrote:
| Please consider bringing back some legacy software.
|
| When I was learning computers, we learned on QNX (poor kids
| younger than I started on Windows!) and there were some very
| interesting software packages that I think don't exist anymore.
|
| For example, QPaint. What made it interesting, is that you could
| save your image in a few image formats, or as a C header for
| inclusion in a C program. It could also import/export Logo
| generated images.
|
| There was also a software voice module. I assume it had different
| voices because when it was demoed to us, it was a robot guy
| voice, but later there was an educational graphical interface
| that looked like a girl's face, and it of course had a female
| voice when it spoke. It would be strange to have two things do
| exactly the same thing, so I suspect they were the same software
| for speech.
|
| I think it was simply invoked with 'speak'. We used to prank
| other students by speak -something- /dev/tty.... where the tty
| pointed to other people's nodes on the server network. Fun times!
| GuestFAUniverse wrote:
| Typical marketing euphemism: "Built-in Support for Open-Source
| Components"
|
| Read: we take free things thankfully, but we don't live by the
| same standards.
| vundercind wrote:
| QNX and BeOS were the only operating systems I tried in the early
| '00s that could make old single-core mid-90s Pentiums feel
| _excellent_ and snappy to use. Far, far better than any Windows
| version, or Linux.
|
| I assume it's mostly scheduler stuff and much better multimedia
| stacks, in both cases. I always hoped the operating systems of
| the future would feel more like that. Closest we've got is
| probably iOS and it cheats by killing processes all the time. The
| future is lame.
| Aurelius108 wrote:
| Although they're cheating, I give them props for trying. I
| abandoned Android when even Samsung didn't make an honest
| effort to make their phones responsive. It's nice that Apple
| consistently values responsiveness because then Google, Samsung
| and Microsoft have some incentive to address their bloated
| products.
| Baeocystin wrote:
| I non-ironically dream for the day that a modern computer is as
| snappy booting as my old Commodore 128, as fast to reset, and
| as responsive to all keystrokes.
| genewitch wrote:
| devuan on vbox boots ~2x slower than CCS64 under emulation.
| If you're talking about "to a desktop" or something, i don't
| do that, i just boot to a shell on devuan and COMMODORE 64
| BASIC V2 on the CCS64
| smallstepforman wrote:
| BeOS was "pervasively" multithreaded, which in non marketing
| speak means the kernel did not have a giant lock (since it was
| designed as a many core system from day #1). Its contemporary
| OS's at the time had a giant single lock. BeOS also had 750ms
| preemption interval (or was it 3ms, I dont remember) while
| Linux and Windows had 20ms, then later 10ms, so this is what
| you fealt. A couple of decades later and most OS's matched the
| finer locking granuality in kernel space, minus the premption
| interval (argument being throughput vs latency, since scripted
| OS benchmarks measure overall throughput, not GUI
| responsiveness). A perfect example is media buffers that
| benefit from smaller buffer sizes, at the cost of less
| throughput. Musicians notice better responsiveness in BeOS,
| hence the monicker "Media OS".
|
| Also, in GUI space, the BeOS/Haiku app server still offers a
| more distributed workload compared to other desktop
| environments. Every windows is assigned its own thread, the app
| gets its own thread, and the app and application server have 1
| thread per app and window to ensure they are not blocked
| waiting for slow app message parsing. So minimum BeOS app with
| graphical "Hello World" window is 4 threads. So even if the app
| is busy, the rest of the system still feels responsive.
|
| All this comes at a throughput cost, as well as an app
| development complexity cost, especially for ported apps. Haiku
| needs to marshall Qt/Gtk/toolkit messages from many windows
| into a single message queue to prevent multithreaded bugs from
| popping up (since in their original environment, all app
| message loopers were not multithreaded). This marshalling needs
| additional lock/unlock calls in Haiku even when not needed
| (messages to same window).
|
| Haiku native apps, on the other hand, are smooth as ice. See
| this screenshot of Medo video editor where all windows are
| working in their own threads (https://raw.githubusercontent.com
| /smallstepforman/Medo/refs/...). On modern systems, this app is
| smooth as ice, which for a video editor is heresy. Disclaimer:
| I wrote the linked Haiku app.
| KerrAvon wrote:
| iOS has very strict process/resource management because it
| wants to preserve both available RAM (for responsiveness) and
| your battery life. I wouldn't call it cheating (even in jest);
| it's a very deliberately and carefully designed feature of the
| OS.
| justin66 wrote:
| @JohnAtQNX the way to put the rug-pulling concerns to bed is to
| license all the source code under the ISC License, BSD 2-clause
| License, or MIT License.
|
| This would certainly have an impact once that was done. Of course
| I cannot speak to what that would do to your software business...
| JohnAtQNX wrote:
| I hear it loud and clear. We're certainly in the early days of
| this initiative, but as things progress I'll make sure to bring
| up source code licensing as a community concern.
| idatum wrote:
| I recall running QNX on my iPAQ handheld, sometime in the late
| 2000s. It was pre-iPhone, so seeing a Unix-like O/S on a handheld
| device back then was quite a treat.
| Baeocystin wrote:
| I still remember being blown away by the single-floppy QNX demo
| that included a web browser. It was so _fast_.
|
| I wish you guys the best. I can only imagine what a gordian knot
| it must be getting all the legal ducks in a row to actually open
| things up. Like others have mentioned, after two rug pulls, we're
| all wary, but there's so much to enjoy about QNX, I hope you
| manage to get traction with this.
| bigiain wrote:
| That QNX demo floppy was _magical_ back in the late 90's,
| revealing just how fast things _could_ feel on a 486 DX2 or DX4
| CPU compared to the same use on Linux/Windows at the time.
|
| I've always had a somewhat positive view of QNX since then, but
| intermediate ownership and open/commercial status changes
| always kept me away from it. Sadly, this "opening" is familiar
| enough, and previous experience lead me to believe unless it
| gets a truly open GPL license and a large enough FOSS community
| to maintain a fork, this'll just get rug pulled again...
| VoxPelli wrote:
| We need to start treating "non-commercial" as the ambivalent term
| that it is.
|
| Eg: All "non-profit" and "personal" use likely isn't necessarily
| "non-commercial", but those two can be easily identified based on
| who it is that makes use of the software.
|
| So what is the definition of "non-commercial"? Nothing in itself.
| Eg. Creative Commons elaborates a lot on what it means in that
| context:
| https://wiki.creativecommons.org/wiki/NonCommercial_interpre...
| kmbfjr wrote:
| What I need to know is, does it come with Solitaire using the
| "Giants of Computing" card deck?
|
| Because if it does, that is worth it right there.
|
| We ran QNX for ASI statistical multiplexing in TV. I would always
| fire up a game while waiting for logs.
| parl_match wrote:
| Why would I use QNX for any project when RTOS Linux is mature?
| Why would I care? So you can rug-pull license changes?
|
| Should I use it because it's cute? It's academically interesting?
| Sure, I've used QNX in the past for those reasons. The next time
| I pick a soc for a project, and its associated bsp, I'm not going
| to look for QNX. I'm either going to use whatever freertos distro
| they include or install the android build tools so i can push an
| apk to its wackity ass android fork.
|
| I suppose if i was doing automotive or medical, the story would
| be different. But I know the space well enough to know that you
| have many competitors all nipping at your heels, and with the
| linux rtos changes, it's not going to get better.
|
| This is not 2010. There are options. While QNX has languished
| behind obscure and annoying licensing requirements, literally
| dozens of companies have been developing alternatives. Some of
| them are quite big, and in some cases, have gone to space.
|
| At this point, if you want QNX to be taken seriously, you're
| going to have to do better than "start opening the doors to QNX
| like things used to be".
|
| I'll take it one step further - if it's not completely open
| source for commercial use, I have no interest in using it. I
| could be enticed to put up with an Epic-style license if the
| associated tooling and bsp support was worth my time. I have zero
| interest in paying a license to get started. Again - not 2010.
|
| Your product has been commoditized and now it's a curiosity. The
| only way it gets enough active development and adoption is if its
| a community effort.
| Dinux wrote:
| Amen
| gosub100 wrote:
| You would use it if you wanted to get a job doing RTOS dev and
| wanted to show you had some skin in the game.
___________________________________________________________________
(page generated 2024-11-07 23:00 UTC)