QNX DEMO disk (1999)
qnx.puslapiai.lt
qnx.puslapiai.lt
QNX started closed source with a free version, went open source, went closed source, went open source after an acquisition, and then went closed source when RIM (Blackberry) acquired them. Then RIM dropped the GUI to focus on whatever it is Blackberry still does.
As I once told one of their sales execs, "quit worrying about people pirating your system and worry about people ignoring it". During the first free version period, people were porting open source software such as GCC, Eclipse, and browsers to QNX. With all the licensing changes, the open source community got fed up with QNX and stopped making versions for it.
We used QNX for our DARPA Grand Challenge vehicle. All our desktop machines ran QNX, and we could run the real-time program on them as well as the vehicle. The real time features were so good that we could have the entire real-time vehicle system running, at hard real time priority, and run a browser or compile without missing a time check.
2- What tech stack (language) you used for those challenges?
3- Your idea on Lisp (for these applications)?
2. C++. Here's the source code. [1]
3. No.
Look into Genode.
Why? No hope for real RT? (Or otherwise more generally due to the GC?)
SeL4 with CAmkES, or Genode.
Huge TCB being the main one.
i.e. The code that needs to be trusted. For Linux, it includes the whole kernel, and it is huge.
device drivers weren't privileged - they were just another process you called into, and could be restarted in the case of a fault (rather than kernel panic or blue screen).
A system that doesn't provide this is not an alternative to QNX; It's just another operating system (which are all, in some ways, alternative to each other and thus QNX, but ...)
I know an RTOS does not guarantee smooth desktop performance but I just would love to try it out to compare.
"Folks, we're going to go ahead and uninstall Gnome and see if we can't get on the ground a little earlier. Should be anywhere from 30 to INT_MAX minutes. In the meantime a flight attendant will be coming around with wired keyboards if you'd like to play a free game of Snake on your Entertainment terminals..."
libc.so.6: version `GLIBC_2.28' not found (required by /usr/bin/snek)"Plan 9 has deadline scheduling out-of-the-box for real-time. It runs on x86-64, 386, Arm v7 and AArch64 (And more): http://doc.cat-v.org/plan_9/real_time/ (mostly obsolete but describes the motivation and implementation)
See proc(3) man page for deadline scheduling (towards the bottom real-time i described): http://man.9front.org/3/proc (I always recommend the actively maintained 9front fork)
The best part is you don't need special patches or libraries. You simply configure the process/group by writing messages to the procs ctl file using the command line, a script, or from within your program.
The true hallmarks of an RTOS kernel is hard-realtime scheduling usually with round-robin priorities, and support for priority inversion, which is when a low priority process blocks a high priority one, it inherits the high priority temporarily to meet the deadline.
Windows is threads have a priority, with the highest priority thread occupying the CPU - however there's a series of 'hacks' that allow it to emulate real time behavior.
Threads can get a priority boost in some cases, such as the aforementioned priority inversion case, when the user interacts with the program associated with the thread, when the thread hasn't run for a long time etc.
Additionally there's a set of 'real-time' priorities that can preempt all non-realtime priorities and you need admin or kernel access to set this prio level, as these threads will lock up your system because they can't be preempted.
While I wouldn't trust Windows to control an ICBM, but it's good enough at giving resources to user processes so the your UI feels responsive.
Driver support wasn't extensive, but the available drivers were working fine. With qnxstart.com at the time and all the oss tooling I didn't have anything missing.
I was in love in a way that only beos gave me before.
This was the last commercial/closed-source OS I ever used in no small part due to the license change.
So no neutrino hosted compiler toolchain, no desktop. Oh yeah, they also completely killed off their full GUI desktop, the Photon microGUI in QNX 6.6. There was even a working port of Mozilla Firefox to it at some point. You could use all this freely with a hobbyist/non-commercial license in the early 2000s.
[0] http://www.qnx.com/developers/docs/7.0.0/index.html#com.qnx....
Edit to add: Just had a scary thought. What if Red Hat and whoever else is actually spending money on desktop Linux development applied the same logic to desktop Linux itself that I retroactively applied to self-hosted QNX? After all, non-developers don't use Linux, right? (I'm speculating that they'd make that assumption, not saying it's actually true.) And developers can work with Linux by connecting to a remote machine or running a VM on a "normal" (i.e. Windows or Mac) computer. Is there enough economic incentive to keep maintaining and improving desktop Linux that this won't happen? The death of desktop Linux wouldn't actually hurt me, as I mainly use Windows, but I'd still be sad.
Self-hosting support doesn’t require PC hardware support. You totally can run your toolchain in a VM (every developer using WSL on Windows is doing it). In the past, I’ve put development environments in Docker containers - it makes it easier for people to get started, and on Windows or macOS that’s a VM too.
Making a system self-hosting is exposing it to a broader range of use cases which can help shake out bugs, limitations and performance issues which other use cases don’t. Even if you don’t strictly need it, I still think it is a good idea to maintain that support (even use it in your CI) unless doing so becomes unjustifiably expensive.
That's a very frequent comment about tech companies with underperforming sales.
This is how ARM leapfrogged MIPS around 2010. Their licensing was basicaly "you are buying a USB stick". MIPS on other hand was "pre-pay us $100k just to have our attorney to take a look on if we can sell to you"
In those "deep" tech companies, it's absolutely not unusual to have sales staffed by people with zero background knowledge, but nevertheless star sales professionals.
edit: poking around https://archive.org/details/software?query=qnx
How they did it: http://web.archive.org/web/20011106140711/http://www.qnx.com...
As a wow factor it probably comes a close second place to when I got to experience BeOS hands-on (which was like, how is that even possible)
We used QNX in my last company as the foundation for our router. It was a "tandem" HA system (at least one of our lead architects were formerly from Tandem, the company). It had 2x Control Plane (1 Active, 1 Standby) boards, and 3x Data Plane boards (2 Active, 1 Standby). QNX was an important part of our architecture.
Some features I loved in QNX: process control across the network. I could control processes on any of the processors (running QNX) on any of the boards of the system. Launch a program on a different processor with just the appropriate command prefix (which I forget). Also, driver restart: by the nature of being a microkernel, drivers were "just another process", and if they crashed or hung I could just restart/kill the process. Also, tighter coupling between drivers and files under /dev, unlike whatever Linux is doing, especially for networking devices!
The router served as a "security endpoint", meaning it could "terminate" (decode), thousands of IPSec connections. Thus it would serve as the "border router" for a network operator.
The company's big hit was providing this product to NTT Docomo for its LTE infrastructure. NTT had the (turned out unique) architectural challenge where they controlled the base stations, the core network... but not the backhaul (connection between the base stations and core)! The backhaul was on shared leased network. So they needed to encrypt [1], hence the IPSec, and hence the need for a "router" that could receive all these connections and decode them to feed into their Core Network.
I joined the company shortly after they scored that huge contract, when they were flush with money and looking to grow.
NTT Docomo was a pioneer in LTE deployment, so our company tried to sell this operating model to the rest of the world... but no-one took it. Turns out most operators just own their backhaul, so didn't feel the need to encrypt, or at least have the same architecture as NTT.
So our company tried for a while to adapt our router (really, network middle-box, and really, its upgraded next version) for other emerging use-cases, but it was hard to get a grip both in emerging network architectures and against the incumbents (lol the number of times we had bugs with Cisco equipment which we proved was Cisco's fault but nope we just had to work around it).
The company was eventually bought at fire sale price by one that did cheap Software-Defined Networking on commodity hardware. Our expensive router was discontinued.
(Also, fuck Broadcom)
[1] It occurs to me that Snowden's revelations in 2013 happened during my tenure there. However the response of many operators was to have one fat encrypted pipe (which we didn't stand out for) rather than many small encrypted ones (which we did).
(edit: also working with NTT Docomo was another level of reliability requirement compared to the half-assery that was tolerated everywhere else!)
BeOS and QNX (Photon) were my two favorite desktop experiences of the bunch. They were so much better than the others—yes, very much including Linux. And BeOS was even at least as "friendly" and polished as Windows was at the time.
Here we are and neither's on the desktop and their closest modern equivalent that is prevalent is probably macOS, which is... fine as a consolation prize, I guess, but I still wish I could see a world where either of those made a real splash in the desktop world (I know QNX wasn't really trying to, but man, it performed so much better as a desktop OS than Windows or Linux).
[0] part of the FS query language, so you could select/filter through file metadata for free.
You know, I think he was right.
The rule of thumb is if FreeBSD supports it then Haiku will, as a number of important drivers were ported from FreeBSD.
That makes perfect sense for that period, the Linux desktop experience was, well, not atrocious, but definitely left things to be desired.
I'm pretty sure it's not much better now but hardware's powerful enough to make that less-painful.
thanks for the reminder!
Prior to SqueakNOS we implemented this: http://swain.webframe.org/squeak/floppy/ (using Linux and modifying Squeak to work with SVGALib instead of X) in just 900mb inspired in this QNX Demo Disk.
TBH, even now, 900 meg isn't very impressive. ;-)
I used to use those ad-supported dial up ISP’s and found one that worked with a standard PPP dialer so I didn’t need their software. I remember carrying around the QNX disk and login info so I could get online with basically any computer.
I never hear about QNX anymore, so this is def a blast from the past.
Juno? Netzero?
I still have a floppy set somewhere. I loved it. I ran it in a 486 IBM all in one I had with a compatible NIC for a long time as a conversation piece and guest light surfing machine. Amazing how well it ran up till fairly recently when standards outstripped its browser too much
I need to rebuild my Ccmp collection. I ended up selling or giving it all away due to having to move. sniff
I ran a NeXTstation Turbo Color as my daily driver up till around 2010. Me and some friends ported over newer line and what not for openstep 4.2.
33mhz 040 with 128mb of 60ns EDO RAM, SCSI HDD. Amazing what you could do with adequate performance on that.
Also ran a BeOS r5 system with massive amounts of hacks and updates for way longer than was really reasonable lol
If I remember correctly, they were moving towards OSS at some point (or at least toward opening it to a wider community). I had it installed in a VM, did some packaging of open source stuff to QNX (bash and irssi, I think), was fun.
At some point they focused on industry/enterprise and that was the end of that for me, but led me to discover L4 later on, and I still have a soft spot for microkernels.
It was amazing that they could fit a semi-functional browser on a floppy.
Here is an old screenshot from ~2003: http://www.xwinman.org/screenshots/fvwm2-taviso.png
All the panels and menus were all fwvm, it's highly configurable. I dunno, it kinda holds up!
https://copy.sh/v86/?profile=qnx
If you're on a Windows system, you may have to go to C:\Windows and temporarily rename the HelpPane.exe system application in order to stop it from hijacking the F1 keypress that QNX expects.
Minix, as cool as it is, does not have a maintainer, and hasn't seen activity for years. There's a lot of out-of-tree work that's just sitting there. It is a shame, because it is a really cool system architecture.
Genode is a modern, proper multiserver OS that has a good architecture, frequent releases and quite solid overall direction. And it has POSIX compatibility, so a lot of software runs, including modern web browser engines.
When done properly about two decades ago it would slingshot it against Linux really well.
Tom's Root-and-Boot just about got you a working command line on one floppy.
For comparison, using FOSS equivalents, QNX got that, plus all of X.org, plus Firefox, onto one floppy.
And if you used the status bar to find your IP address, and went to another machine and put that in a browser's URL box, you found that as well as all that, it was also a live webserver, serving live performance stats to the Internet.
So, kernel, busybox, X server, desktop, web browser AND WEB SERVER on one (very heavily compressed) floppy.
Sadly, the genius who built it died young. Cancer. Fsck cancer.
Except it’s not really ALL of X, and the browser is more like IE2 in capabilities…
For a more fair comparison, where QNX wins in terms of absolute size, but Linux wins in terms of functionality, there’s muLinux: http://micheleandreoli.org/public/Software/mulinux/
So snappy and smooth compared to Windows 3.11 on the same 2MB 386.
EDIT: I think I found a link for it:
https://eqip.openqnx.com/sites/eqip.openqnx.com/files/ipaq_b...
You could have a file system with much less disk-space overhead than FAT, and there are many out there. A demo disk would typically be read-only, and in particular there are some read-only file-systems that are really space-optimised,
Another option would be to treat the disk sectors as a single compressed file which the bootloader decompresses into a RAM-disk image which the OS then boots from, but that would require a bit more than 2 MB of RAM.
I can't help but to find the min-max of everything. Well at least fantasize about what could be.
The full OS was a ~100MB download:
https://archive.org/details/qnx-neutrino-rtos-x86-runtime-ki...
But it depends what you define as "the full OS".
It is mainly an embedded OS for routers and engine-control units and traffic lights. For that role, it doesn't need a GUI or a desktop or dev tools or a network stack.
So are they part of the "full OS"?
It depends where you stand, and how you look at it.
The Demo Disk contains a lot more than 1.4MB of code. It's more like 3-4MB of code, but that does not mean it is "the full OS".
Also, Coca-Cola’s kiosks for drink selection uses QNX.
In both cases, they’re using Qt instead of Photon.
Photon was just about perfect as a GUI architecture IMHO, although I don’t know if it could have handled an alpha compositing as well as it handled blit stuff across a network connection.
We had QNX running on a system called an ICON, which had lots of bells and whistles that made using them quite fun. It came with all the languages (the year-after students only learned BASIC and Turing), and had a voice synthesizer. Oh, and way better graphics - you could draw something in QPaint or Logo, and then export it as a header file to use in your C, Pascal, etc programs. We used that functionality for making splash screens for our assignments, even though that wasn't an actual requirement.
The only issue was the file system and driver support - if it crashed there was not good recovery tools.
Why can't we run one of those on a generic Linux kernel?
The 4.0 version works perfectly, 2.2.26 kernel though which was released in 1999
Discussed before here https://news.ycombinator.com/item?id=28515025
Downloads here:
https://winworldpc.com/product/qnx/144mb-demo
Screenshots here:
Glad you enjoyed it!
Honestly I'm still impressed. It was astonishing at the time.
It always seemed too "big" (too capable, too complex, too pricey) for my projects so I never took it for a spin.
I remember playing with menuet os and some other linux “floppydistros” back in the day…
Novell donated the trademark to them when it bought Bell Labs in 1993.
1 Linux is currently a registered UNIX™: Huawei EulerOS
https://www.opengroup.org/openbrand/register/brand3622.htm
Formerly Inspur K-UX was, too:
https://www.opengroup.org/openbrand/register/brand3617.htm
You can view the list here:
https://www.opengroup.org/openbrand/register/
Apple macOS, IBM AIX, HP-UX, the 2 old SCO OSes, and -- oddly -- IBM z/OS.
But no, UNIX is very much not generic, and I generally find Linux people get very upset when I call it a UNIX. Which it is, but even 29 years on, people still think that "Unix" means "based on AT&T code".
You can argue all you want that Minix (the most popular Unix in existence) or Ubuntu (most popular Linux distro in existence) aren't Unix. They're Unix. They're probably more Unix than most Unices on that list. Some company owning the brand and enforcing some arbitrary licensing scheme doesn't change that.
But that is not what the mainstream industry takes it to mean.
Whereas terms like xNix are, I submit, well understood.
It is certainly one solution.
As I recall, it was quite a long time after Linux was a thing that someone trademarked the name and donated it to the LF.
It seems like the only way is for most of the code in the system to contribute to a multitude of different uses... Maybe an interpreter with especially powerful, composable operations and a very compact representation, and most of the system coded to that interpreter? (That got Apollo 11 from orbit to the moon and back.)
Two really good designers, Gorden Bell and Dan Dodge.
Here are the key design decisions:
- All the kernel does is manage memory, dispatch processes, handle interrupts and timers, and pass messages from process to process. No device drivers, no file systems. Everything else is in user space. The kernel is small (about 60KB of code in some versions), very well written, and rarely changed. It's so small, so heavily used, and so rarely changed that it reached an essentially bug-free state.
- All non-preemptable kernel operations have fixed upper bounds on how long they can take, worst case. That upper bound is in microseconds. That's why real time works.
- Message passing and CPU scheduling are integrated and very efficient. In particular, the case of sending a message to another process and getting a reply message is not only low overhead, but does not involve losing your turn for the CPU. The two systems are designed together. So calling another process can be used almost like a subroutine call. Most interprocess message systems botch this, and calling another process means two or more trips through the CPU scheduler and may cost you your CPU quantum. Which means a "microservice architecture" runs too slowly. Which means people work around making interprocess calls, putting too much in one process.
- There is no swapping or paging. This is essential for real-time. It simplifies other things. Message passing is copying user space to user space, and can't page fault. The destination area has to be in memory. So there is no need for kernel data buffers.
- At boot time, the boot program loads the kernel, a user space utility process called "proc", plus any user space drivers or programs you want at startup. That's how it gets started with no device drivers in the kernel. More drivers can be loaded later, if desired. Having a file system or disk is optional. The minimal configuration is a CPU, boot ROM with the software, and memory. That's a common configuration for small embedded systems.
- File systems, networking, and drivers are all user programs. Some have the privilege of writing to device space. The kernel turns interrupts into interprocess messages.
It's a nice architecture for small and medium real-time systems that have to Just Work.
Any numbers on the overhead of a message send/reply round trip compared to a subroutine call? I always assumed it was just axiomatic that the difference in latency between those two options would be orders of magnitude.
[1] http://support.qnx.com/developers/docs/6.5.0/index.jsp?topic...
Teading the old open sourced sources can be quite interesting...
https://github.com/vocho/openqnx/tree/master/trunk/lib/qnx43...
The idea that the kernel does so little is really cool. I don’t know if it’d work at the true microcontroller level where 128k is precious memory but I can definitely see the larger microcontrollers that exist now or even stuff like fpga socs being useful with this sort of setup. Sounds cool.