> (using Linux and modifying Squeak to work with SVGALib instead of X)
> in just 900mb
"Just" 900MB?
That is, er, not very comparable. Nearly a gigabyte, versus a single floppy? (Circa 1.4MB albeit very heavily compressed, so over 2MB of code, maybe 3.)
That is a difference of approximately 2 orders of magnitude, heading towards 3 OOM: 1000x bigger.
Am I misreading?
You definitely did not get 900MB on a floppy. It wouldn't even fit on a CD (~700MB uncompressed).
QNX on the ICON was full of bad security form in general, including default passwords for root, supervisor, teacher, and icon (blank) that were rarely changed in the classroom and could be found in the manual at the front of the room: https://jasoneckert.github.io/myblog/icon-computer/
The ICON was the first computer that I used that had a multi-user interface. Teachers were not trained well and "computer security" was not something that had yet seriously entered our language.
While programming them for class was interesting, the real fun was trying to get "cool stuff" to work. We learned BASIC and Pascal in class, but we hacked C and wrote interesting shell scripts after our code worked.
Kind of cool to see where it ended up (with BBY and all).
Indeed, when I was in eighth grade we had “reading buddies” in the grade 1 class where older kids would go read the younger children stories. The teacher of the grade 1 class had an internal memo posted on the bulletin board explaining teachers’ usernames were their last name and password was their first name. So after I saw that I could get teacher-level access by knowing any teacher’s first name.
From there it was possible to trackball-and-ACTION-key my way to administrator permissions which is maybe what the bug referred to in GP was referring to?
Anyways my big mistake was sharing this information with my classmates — it was fun to change the login message for everyone to a kind of “so long suckers” just before we graduated, but apparently someone changed the admin password and (presumably due to not being aware of the bug) locked them out.
The vice principal had me come back to school after graduating to be chewed out and told that they nearly charged me with mischief :-/
When I got to high school I mostly just had fun finding a way to drop into the command line and playing around with that instead of working around access controls…
I also remember having to work around the lack of environment variables (in the 80s I think), but reading through the Wikipedia entry it looks like that restriction is long gone.
Wow, that's a throwback. I remember when my Ontario high-school in '84 or '85 got a whole room full of ICON computers. It was a total miserable nightmare for the teaching staff as each computer class had at least a couple of students with the skills to elevate themselves to root privileges and cause constant mischief.
The ICONs were way more fun from the aging Commodore Pets that had populated Ontario high-schools, and the big trackballs felt futuristic.
Yes! By the time I was in high school in Ontario (early 90s) we had PCs as I recall, but in grade school there were Pets and then later ICONs. At home a lot of kids had C64s, though my family’s first machine was an IBM XT clone.
I vaguely remember a mysterious “other room” where ICON-related things happened - this must have been where the LEXICON server was located.
...no longer the only true microkernel in industry (the paper was written in 1992, back then QNX was certainly leading in this respect). Nowadays, open source as well as commercial L4-based microkernels are widely used, e.g. seL4 (UNSW), Fiasco (TU Dresden) and PikeOS (SYSGO).
It was in the Playbook, the cancelled Folio, and a lot of smartphones, such as the Passport I used to own. (A lovely device, sadly crippled as messaging app vendors removed support. I could use Android apps on it, but they didn't integrate into the Blackberry Hub.)
It was also very nearly the next-gen Amiga, which I suspect is why it has a GUI and multimedia support.
I suspect that between routers, switches, engine control units, traffic signals, smartphones, car entertainment units, and doubtless many other things we don't hear about, it's in more devices in production than all of seL4, Fiasco, etc. put together.
Minix 3 is arguably also a true microkernel, and it's present in industry, embedded in millions of Intel Xeon and Core iX CPUs' management units, but it never reached a state of much completeness. No SMP support, for instance, and a lot of missing functionality.
You can take that to the bank. I wouldn't be surprised if there are machines that people have completely forgotten about that still happily churn away and if they ever do fail suddenly we'll notice. Let's hope it's not a power dam or some other critical bit of infra.
Blackberry 10 was so nice. I bought a Z10 at launch, UX-wise the best phone I ever had. Used it for I think 3 years and would go back instantly with a modern device and better app support.
It had gesture control years before Android and iOS introduced them (it was copied from MeeGo though) and the unified inbox is still miles a way from everything else.
It was the inbox that sold me on it. I had to occasionally manually kill background apps; I could feel the phone getting hot in my pocket sometimes, as something burned CPU and battery. It was a bit version-1-point-zero.
But, a good UI, most Android apps worked... but slowly, over time, Whatsapp dropped support, FB Messenger dropped support, and while the Android clients worked, they no longer integrated with the unified inbox, making it all a bit pointless.
For those who never saw it:
BB10 was QNX with a Qt-based GUI on top. It had a global inbox, part of the home screen, and all messages appeared in it. Work emails, personal emails, all chat systems, app notifications -- all in one place, sortable and searchable. It sounds like a lot to deal with but it wasn't; it was much easier than handling notifications and messages on iOS or Android, where they are spread over a dozen different apps.
Android "native" apps are actually Java apps in a customised Java runtime, a modified JVM. This has been completely replaced several times over the lifetime of Android.
BB10 had its own Android-compatible JVM, so Android apps ran on BB10, at peer level with native apps. The big snag was that there were no Google apps, and Android apps assume those are present. So, if an app displays a map, it assumes Google Maps and blindly calls it, and if that app is not there, the exception is unhandled and you get a blank area on screen where the map should be.
Sadly sideloading the Google Apps did not fix this. They worked but they were not where expected, or sandboxed, or something. Some, e.g. Google Translate, worked badly because it assumes an onscreen keyboard but the Blackberries didn't have one because they have permanent hardware keyboards.
A lot of these UI ideas (unified inbox, the cards & gestures for multitasking, etc.) were taken straight from Palm WebOS. Palm called the unified messaging "Synergy" and it applied to calendars, chat, and emails; the OS provided a unified API for all such products to work together and it worked pretty well for the time.
I suspect app developers aren't really a fan of this as half the reason they're building such a tool is to have a branded environment to capture your attention in....
Of course WebOS also died in an ignoble fashion as BB10. Its UI DNA does live on at Google in some ways though as the head of UX at Palm (Mathias Duarte) eventually became VP of design at Google. When Android & iOS eventually rolled out multitasking gestures it looked a lot like WebOS.
That's interesting -- I was only vaguely aware of that.
The deal that nearly happened between PalmSource and Symbian when Palm was moving to Arm processors is one of the great might-have-beens of the IT industry.
Symbian was a superb OS, with a choice of UIs not of which matched its greatness.
Palm had a very good, widely-loved UI, but a poor kernel underneath.
The combination could have been industry-beating, but the deal never completed.
Now Symbian is FOSS but nobody cares, and PalmOS is buried inside Access Corp, never to be seen again.
I think WebOS survives as the UI of some LG smart TVs...
The WebOS UI in the LG TVs doesn't have much connection to the phone OS's UI at this point, though it's from the same code base originally, yes. From my understanding, same idea of building apps in an HTML/JS stack, and using some of the original SDK.
> if an app displays a map, it assumes Google Maps and blindly calls it
I seem to recall that one was fixed down the road and displayed the native map.
> Blackberries didn't have one because they have permanent hardware keyboards
Not the Z10, which was fully touch. This gave a good experience for these Android apps, especially if you sideloaded the Amazon app store and picked from that.
I was recently talking about the Z10 being the best phone I have owned. It lacked app support otherwise I would have used it longer. Unified inbox is what I miss most about it.
Got a Z10 at launch, I did not expect it to be _that_ good, but it was! Especially with the latest updates which added a ton of new features and improvements.
The software keyboard was incredibly reactive and tactile; I bet QNX played its part on that.
Had to stop using it because of stupid (Android) bank apps deciding to check for root and refused to run.
Interesting! I don't remember ever hearing about that at the time. I'm not saying that I don't believe you, but I'd be very interested if you had any links or references for that.
For the three years (2002-2005) I worked on a DARPA Grand Challenge vehicle, my main desktop machine ran QNX. I could build and run the real time software on it, connected to either a simulator or cabled to the actual vehicle up on jacks.
Mistake on my part: I thought it was a cancelled Blackberry device, but it wasn't -- it was a cancelled Palm device.
Before the rise of netbooks, it was a netbook-sized terminal to a smartphone that let you use a laptop-style UI to your email and so on, by being tethered to a smartphone.
L4 is more of a hypervisor. You have to run another OS, usually Linux, on top of it. So the overall system complexity has been increased, rather than reduced. QNX offers a POSIX-type API, so you can run applications on it directly,
It's not for industry, but I keep mentioning it because it's so surprising and little known: The Nintendo Switch uses a home-grown microkernel. It's not UNIX-compatible, fits into ~30K lines of code IIRC, and everything from the USB to the Graphics drivers are sandboxed in userspace. (Too bad NVIDIA's Secure Boot code didn't match Nintendo's standards.)
> Nintendo is exempt from GPLv2 licensing and may (at its option) instead license any source code authored for the libmesosphere project under the Zero-Clause BSD license.
Er, what? Why would a 3rd-party reimplementation allow Nintendo to use their work?
Probably because it's based entirely on (non-black-box) reverse-engineered Switch binaries, and is therefore very possibly a derivative work of Nintendo's copyrighted code.
Literally nothing I have ever read about Nintendo makes me think this would even give them a moment of pause as they sue the author into oblivion. (This is a comment on Nintendo's behavior, not the legality of the author's actions.)
I've worked with QNX for years and wrote a clone, this is an amazing little OS that you can build rock solid services on. It's a pity that there never was much interest in something along these lines but open source.
I was going to ask if someone had written a clone. As in "if QNX is so tiny and elegant, surely it must be easy to clone!" - I'm sure it was harder than it seems.
Do you have a link to your version? How compatible was it?
100% compatible at the call level. Another HN'er has actually managed to resurrect it partially. And no, I don't have a link and the project is not in a presentable state.
I would have loved to see an open-source of something like QNX for music production, as it would be very useful for its hard realtime guarantees and low latency.
In my experience Linux has been pretty awful at this.
> In my experience Linux has been pretty awful at this.
isn't the problem these days just crappy random hardware more than anything else; Linux itself, especially with rt patches, together with jack should have good enough rt perf for audio use. I've seen reports of <5ms roundtrip audio latency on linux even with usb hardware.
The preemptrt patchset (now making its way into mainline) has excellent support for realtime scheduling. The problem is (as it has always been) undocumented NMIs in bog-standard COTS board firmwares. See the `hwlatdetect` man page for details.
I've seen FreeRTOS being used besides QNX and other proprietary RTOSes in automotive applications. Do you know how similar or different FreeRTOS and QNX are?
Yes it is. It's more or less a scheduler library, that you link together with all the other code you have to get a microcontroller system image. There are no processes in FreeRTOS, just tasks (threads).
QNX was the OS that Navigator, show control software, runs on. I ran it for over 6 years, and it was bullet proof and snappy. Isn't Minix a microkernel too? What makes Minix an untrue microkernel? I ran Minix back in the day - 1990s.
Minix 3 totally is, but it's also incomplete, and as Dr Tanenbaum has retired, it probably always will be.
Mach was valid, but the only successful version, Apple's macOS, has a huge in-kernel "Unix server" derived from FreeBSD code, so it's not a microkernel any more.
The OSF's OSF/1 is long gone. So is MkLinux.
IPC performance killed Mach, which led to L4, seL4 and many others, none of which have ever gone mainstream or been widely deployed in production, AFAIK.
AmigaOS does not count, because it has no memory protection: all code runs in a single memory space, which makes a microkernel-like design simple, as there are no barriers to interprocess communication -- but also no use of an MMU chip whatsoever and as a result it was and is as unstable as classic MacOS or Windows 3.x.
I'll bet you a signed dollar it is not being run as a multi-server, microkernel based OS. I'd go further and say L4 being designed as microkernel is nothing more than an amusing piece of trivia in it's use by Apple and that the actual OS that does stuff will be as monolithic as any other used by apple.
Actually, iOS/macOS itself isn't a monolithic OS anymore as many of the important hardware drivers like wifi have moved to userland processes. Of course, it was never fully monolithic because it does upcalls for things like NFS mounts and disk images.
Fuchsia's Zircon might count also. Google used to specifically call it a microkernel. Though they updated the descriptive language to just "kernel" after it drifted further from LK and the number of syscalls got pretty high.
We ran our POS systems on it (server-thin dumb client) - the server was a 64MB 486 and the POS terminals ran a simple client program that emulated an NCR1255 POS terminal.
It just sent keystrokes or print a line on a receipt printer or display a message.
The server was a C program with a giant state machine of up to 64 POS terminals and it hardly broke out in a sweat and used shared memory to talk to other programs that did the card payments and data storage.
It had a footing in the automotive industry long before Blackberry even existed. Also: process control, medical, avionics, transportation. Anything where latency matters more than throughput.
One of the more popular core/edge router platforms used to run QNX for their control plane, Cisco CSR/ASR. Though they switched to Linux some years ago.
Depends on the series. IOS XR is QNX based, IOS XE is Linux based, "plain" IOS is the classic IOS on bare metal, and NX-OS is completely separate development based on Linux that powers Nexus switches.
XR is not QNX-based anymore. They switched over to Wind River 64-bit Linux[1] starting from the newer ASR9k linecards and the NCS series and onwards. The two XR variants are referred to internally as cXR (QNX) and eXR (Linux).
XR itself is mostly the same codebase - it’s just the platform- and OS-specific code that had to be changed. Also, I believe endianness-dependent code had to be ifdef’d.
now that you've outed yourself as an IOS-XR dev I have to ask: why does Cisco have so many darn OSes?
at work I built a system to run Python scripts on various network devices, with a HAL abstracting the APIs. supporting IOS-XR, IOS-XE and NX-OS was quite a bit of work. plus there were so many modes.. netconf-YANG? or show run/config syntax? and so many changes between revisions. meanwhile, the HALs for Juniper and Arista devices were pretty easy.
The honest answer? I have no idea! But I can share what I do know and/or heard when I worked there.
I have zero knowledge about NX-OS. But I can say that the XR and XE teams were quite isolated from one another. For instance, as an XR dev, I had no visibility into XE development.
It kind of makes sense: XE and XR target different device segments, which means the feature sets and scale and availability requirements were different. But both were spun off from IOS, which is why the “base” is common.
I don’t have any visibility into what they’re doing now, but I wouldn’t be surprised if they’re working to unify XE and XR at some level.
Yes, in millions of millions of cars. It power most of the HMI systems in cars, except some newer ones, which are based on Android Auto and very view exceptions based on Windows Embedded/Auto.
This. My car (Porsche Panamera from 2013) runs QNX for its nav+soundsytem. I can stream from bluetooth or use a jack plug but I don't bother: the car's got its own storage for music and, notably, the system takes both .mp3 and .wav files, but not .flac files. So at home I play .flac files but for the car I convert my music to 320 kbps .mp3 (I think I can put about 5000 320 kbps .mp3 in the car). In 2013 Porsche was still putting HDD and not SSD in their cars: some people do the upgrade themselves to a SSD but in my case that would void my extended manufacturer warranty (which I plan to extend up until 15 years / 200 000 km).
Since then, for newer models, the manufacturer has moved the nav+infotainment to Apple's iOS CarPlay. I don't know if QNX is still used for other stuff (like reporting the oil level / warning messages etc.).
> It power most of the HMI systems in cars, except some newer ones, which are based on Android Auto and very view exceptions based on Windows Embedded/Auto.
My Ford has had both. As a 2015 model it shipped with MyFordTouch which ran on whatever Microsoft was calling the automotive branch of Windows CE at the time (AutoPC?) with a UI built in Adobe Flash.
2016 and newer models got a QNX-based platform with a HTML5 UI under the name SYNC 3, and the newer SYNC 4 variants are derived from that.
I upgraded my car with parts from a 2016 model a few years ago because Sync 3 could do Android Auto and CarPlay where MyFordTouch could not.
It is Blackberry's main source of revenue at this point is my understanding. Heavy use in automotive sector. 215 million automotive installations is the number I heard.
Back when I toiled in trenches as an embedded systems developer, I always dreamed of being able to use a "big, proper" OS like QNX instead of whatever clumsy, barely-better-than-bare-metal RTOS I was using at the time. I remember QNX always having a decent presence at the embedded systems conference.
Instead of going unix-ish and using QNX we eventually went windows-ish and used Phar Lap ETS, which was quite nice and civilized.
http://toastytech.com/guis/qnxdemo.html