Linked by Thom Holwerda on Fri 28th Apr 2017 22:19 UTC, submitted by elahav
QNX

BlackBerry QNX is an embedded operating system targeting applications in the automotive, general embedded, and medical markets. However, it is not your garden-variety embedded OS: QNX is a full-blown, UNIX-like, POSIX-compliant operating system with all of the features you would expect of a desktop or server-class OS. Compatibility with other systems means that, at least in theory, porting various open source projects to SDP 7 should be a relatively easy task. And so, while there is no official support in this release for a desktop environment, there is nothing precluding someone from building such a system. With that in mind, I set myself the task of building a BlackBerry QNX 7 desktop.

Written by QNX kernel developer Elad Lahav, so you know the information in this article is solid.

Order by: Score:
What happened to Photon?
by cybergorf on Fri 28th Apr 2017 23:15 UTC
cybergorf
Member since:
2008-06-30

If I remember correctly QNX used to ship with a window manager ages ago - it was called Photon. Quite fast and powerful even without any hardware acceleration. What happened to it?

Reply Score: 6

RE: What happened to Photon?
by Morgan on Sat 29th Apr 2017 03:26 UTC in reply to "What happened to Photon?"
Morgan Member since:
2005-06-29

I miss playing around in Photon, it was actually quite advanced for its time and for being mostly a dogfooding experiment. I think the last time I played with it was in the QNX Momentics 6 release some time in the early/mid 2000s. I had it booting with full hardware support on a PIII based Acer machine, that also coincidentally ran BeOS R5 with all hardware working.

Reply Score: 3

RE: What happened to Photon?
by MarkHughes on Sat 29th Apr 2017 08:30 UTC in reply to "What happened to Photon?"
MarkHughes Member since:
2013-11-14

Yes, I won a copy of it on CD many years ago (Version 4 I think it was) It was really fast and great looking, There was also a demo on a single floppy that booted to the desktop and had a browser and some other software all on the one disk.

I seem to recall it was modular so you only installed the parts you needed making it small and fast with no bloat.

If they positioned an updated version in the market to compete with current stuff I would certainly be interested and I am sure many other folk would be too.

Reply Score: 1

RE[2]: What happened to Photon?
by andreww591 on Sat 29th Apr 2017 12:38 UTC in reply to "RE: What happened to Photon?"
andreww591 Member since:
2015-11-01

QNX completely gave up on desktops several years ago when they replaced Photon with Screen, but even before that, the non-commercial versions had been increasingly crippled. The only QNX versions that had full non-commercial distributions were 6.0 and 6.1 (which both came out in 2001). I think QNX's proprietary license has held it back considerably in many ways.

I wonder how things would have turned out if QNX had been a research OS under a free (or at least semi-free) license. It might have stopped Mach from single-handedly destroying the reputation of microkernels. We might all be using microkernel OSes had QNX been free like Mach was.

I'm going to try to fix the lack of a free QNX-like OS (no, Minix 3 and GNU/Hurd don't count as far as I'm concerned) by writing one myself. I have much of the design already planned out and have been thinking about the best ways to do things for quite a few years now. My OS will be called UX/RT and while it won't be a clone of QNX at all, it will have a broadly similar architecture. I'm not cloning QNX because I want to improve on it in some ways (among other differences from QNX, UX/RT will have a fully unified filesystem-based IPC API, and will have support for process-specific namespaces like those of Plan 9). Linux binary compatibility will be a top priority, and that should mostly solve the problem of application support. Driver support will also mostly be taken care of by Linux compatibility (there are already a couple of "Linux kernel as a library" projects that should be possible to use to provide device, network, and disk filesystem drivers). Hopefully the Linux application and driver support should make it at least somewhat successful as an alternative OS.

Edited 2017-04-29 12:42 UTC

Reply Score: 4

RE[3]: What happened to Photon?
by MarkHughes on Sat 29th Apr 2017 14:00 UTC in reply to "RE[2]: What happened to Photon?"
MarkHughes Member since:
2013-11-14

I would like to hear more about this, Do you have a website or anything to follow ?

Reply Score: 2

RE[4]: What happened to Photon?
by andreww591 on Sun 30th Apr 2017 04:27 UTC in reply to "RE[3]: What happened to Photon?"
andreww591 Member since:
2015-11-01

I would like to hear more about this, Do you have a website or anything to follow ?


I did create a Sourceforge site several years ago but I haven't uploaded much to it and haven't made a lot of progress since then (and changed my plans some since then as well).

I really should create a GitLab/GitHub repository. Currently I just have an in-memory bootloader although I've almost gotten it into a useful state (I did have it working a while ago but I decided to change the boot protocol since it wasn't extensible enough). Next thing to do after that is to patch seL4 to support QNX-like booting from a memory filesystem image as well as an early video console.

Reply Score: 1

RE[3]: What happened to Photon?
by Megol on Sat 29th Apr 2017 14:39 UTC in reply to "RE[2]: What happened to Photon?"
Megol Member since:
2011-04-11

QNX completely gave up on desktops several years ago when they replaced Photon with Screen, but even before that, the non-commercial versions had been increasingly crippled. The only QNX versions that had full non-commercial distributions were 6.0 and 6.1 (which both came out in 2001). I think QNX's proprietary license has held it back considerably in many ways.


I actually don't think so. The reason is that one wouldn't need an open license to develop an open system if QNX had decided to support that. Making hobbyist use of the core elements free while making commercial users and users of specific extensions pay could have helped.

But didn't they try that some time after the Amiga deal fell through? They opened up the source and made it possible for hobbyists to use the system at home. It didn't help much.


I wonder how things would have turned out if QNX had been a research OS under a free (or at least semi-free) license. It might have stopped Mach from single-handedly destroying the reputation of microkernels. We might all be using microkernel OSes had QNX been free like Mach was.


Not likely. The first versions of Mach were tightly integrated into Unix code. They weren't free.


I'm going to try to fix the lack of a free QNX-like OS (no, Minix 3 and GNU/Hurd don't count as far as I'm concerned) by writing one myself. I have much of the design already planned out and have been thinking about the best ways to do things for quite a few years now. My OS will be called UX/RT and while it won't be a clone of QNX at all, it will have a broadly similar architecture. I'm not cloning QNX because I want to improve on it in some ways (among other differences from QNX, UX/RT will have a fully unified filesystem-based IPC API, and will have support for process-specific namespaces like those of Plan 9). Linux binary compatibility will be a top priority, and that should mostly solve the problem of application support. Driver support will also mostly be taken care of by Linux compatibility (there are already a couple of "Linux kernel as a library" projects that should be possible to use to provide device, network, and disk filesystem drivers). Hopefully the Linux application and driver support should make it at least somewhat successful as an alternative OS.


Plan9 type local namespaces is a straight-forward extension of the current namespace management of QNX, just add more namespace roots.

I don't know what "fully unified filesystem-based IPC API" means however the IPC design of QNX Neutrino is strongly connected to the filesystem management. Essentially an IPC channel can be viewed as a handle to a file. Don't know if extending that IPC-filesystem connection is wise as the IPC system have to be as fast as possible.

Retrofitting Linux drivers into a microkernel isn't likely to lead to something good IMHO - the driver models differ too much.

BTW there once was a project to combine ideas from both QNX and Plan9, it could perhaps be of interest?
https://en.wikipedia.org/wiki/VSTa

Reply Score: 1

RE[4]: What happened to Photon?
by andreww591 on Sun 30th Apr 2017 04:05 UTC in reply to "RE[3]: What happened to Photon?"
andreww591 Member since:
2015-11-01



I actually don't think so. The reason is that one wouldn't need an open license to develop an open system if QNX had decided to support that. Making hobbyist use of the core elements free while making commercial users and users of specific extensions pay could have helped.

But didn't they try that some time after the Amiga deal fell through? They opened up the source and made it possible for hobbyists to use the system at home. It didn't help much.


I'd think even with semi-free non-commercial licensing, a lot of people would still choose Linux over QNX simply because Linux is free.


Not likely. The first versions of Mach were tightly integrated into Unix code. They weren't free.


I thought Mach itself was always free or semi-free but the BSD code it incorporated was encumbered, whereas AFAIK QNX was 100% proprietary without even limited source availability until their brief experiment with releasing it under a semi-free "shared source" license.


I don't know what "fully unified filesystem-based IPC API" means however the IPC design of QNX Neutrino is strongly connected to the filesystem management. Essentially an IPC channel can be viewed as a handle to a file. Don't know if extending that IPC-filesystem connection is wise as the IPC system have to be as fast as possible.


In QNX it's possible to use the IPC in ways that are incompatible. Processes using read()/write() are often incompatible with those that use the kernel messaging API directly. In UX/RT, all IPC APIs will be compatible, and processes will be able to use read()/write(), a message-register-based API, or a shared-buffer-based API without having to worry about what the process at the other end uses (internally read()/write() will use either the register-based or buffer-based API depending on the length of the message; the message- and buffer-based APIs will also auto-copy messages between registers and buffers if the message is of the other type).

Another major difference is that UX/RT will have a capability-based filesystem model (that maps file descriptors onto groups of kernel capabilities) in which the VFS layer alone checking permissions, unlike in QNX where every server must check the permissions of the client process.

Still another difference in the UX/RT filesystem model is that all servers will export a "server port" like in Plan 9, and the server port will then be mounted with the mount command, unlike in QNX where there are two types of filesystem servers both of which often implicitly mount their filesystem on either a fixed path or a path specified through a server-specific option.


Retrofitting Linux drivers into a microkernel isn't likely to lead to something good IMHO - the driver models differ too much.


The drivers won't be part of the kernel. They'll be part of a library that is linked with the disk server and network stack.


BTW there once was a project to combine ideas from both QNX and Plan9, it could perhaps be of interest?
https://en.wikipedia.org/wiki/VSTa


Yeah, I've experimented with VSTa a little and it's the most QNX-like free OS but it's still not quite what I want. For one, it implements processes in the kernel, whereas UX/RT will be based on seL4 and (similar to QNX) will have a process server that also implements filesystem namespace management (although unlike QNX the process server will be a separate binary rather than being built into the kernel). Also, it's written in C, whereas UX/RT will use Rust for new code (although there will still be a lot of C code borrowed from Linux and BSD of course).

Reply Score: 2

RE[5]: What happened to Photon?
by elahav on Sun 30th Apr 2017 11:39 UTC in reply to "RE[4]: What happened to Photon?"
elahav Member since:
2009-05-28


Another major difference is that UX/RT will have a capability-based filesystem model (that maps file descriptors onto groups of kernel capabilities) in which the VFS layer alone checking permissions, unlike in QNX where every server must check the permissions of the client process.


Which entity checks permissions has always been an interesting topic in the design of microkernels. As you mention, in QNX this is mostly done by the server, though QNX 7 also has channel abilities to prevent you from connecting to particular servers.
The alternative, which you suggest, has the major disadvantage that another entity (either the kernel or an external path manager) needs to mirror all nodes provided by all servers (and, in particular, all files and directories in all file systems) in order to enforce permission checks (which also makes it extremely hard to dynamically mount and unmount remote file systems). In QNX, the path manager is oblivious of any nodes other than the mount points of the various servers.
Neither solution is perfect...

Reply Score: 1

RE[3]: What happened to Photon?
by elahav on Sun 30th Apr 2017 11:32 UTC in reply to "RE[2]: What happened to Photon?"
elahav Member since:
2009-05-28

Writing a new OS with a slick, clean, design that can output "Hello World" over a serial connection is not hard. Once you get there, however, you are faced with two problems:
1. Lack of drivers
2. Lack of applications
(And that is assuming you are writing your own file system, network stack and display manager, which are not trivial).

Unless you are Microsoft, Google or Apple, you cannot get hardware vendors to write drivers for your system, or application vendors to port their software. Even BlackBerry at its heyday had trouble with that, and QNX today, even though quite popular in certain segments with millions of deployments, is facing this challenge.
At that point, as a small OS vendor, your only recourse is to make your system compatible with other systems, at which point your slick, clean design breaks apart (or becomes horribly inefficient, which is what happened to most microkernel systems).

Reply Score: 2

RE[4]: What happened to Photon?
by Alfman on Sun 30th Apr 2017 12:03 UTC in reply to "RE[3]: What happened to Photon?"
Alfman Member since:
2011-01-28

elahav,

Writing a new OS with a slick, clean, design that can output "Hello World" over a serial connection is not hard. Once you get there, however, you are faced with two problems:
1. Lack of drivers
2. Lack of applications
(And that is assuming you are writing your own file system, network stack and display manager, which are not trivial).

Unless you are Microsoft, Google or Apple, you cannot get hardware vendors to write drivers for your system, or application vendors to port their software.


As someone's who's been there, I completely agree with everything you said. It's only gotten worse since the times when I was doing my own kernel since these days you've got more proprietary chipsets than ever. It's not for lack of talent or effort, just the lack of mindshare. I was quite passionate about OS development back in the day, but I had to move on. I thought (and still think) there are some things I could do better than something like linux, but indy projects really don't have any widespread viability due to the issues you bring up.

Consolidation has annihilated independent operating systems, the world doesn't need or want more operating systems even if developers can build them.

Edited 2017-04-30 12:21 UTC

Reply Score: 2

RE[4]: What happened to Photon?
by cybergorf on Sun 30th Apr 2017 18:43 UTC in reply to "RE[3]: What happened to Photon?"
cybergorf Member since:
2008-06-30


Unless you are Microsoft, Google or Apple, you cannot get hardware vendors to write drivers for your system, or application vendors to port their software.


Lets see what Google brings to the table with Fuchsia

Reply Score: 1

RE[4]: What happened to Photon?
by Megol on Sun 30th Apr 2017 20:43 UTC in reply to "RE[3]: What happened to Photon?"
Megol Member since:
2011-04-11

Writing a new OS with a slick, clean, design that can output "Hello World" over a serial connection is not hard. Once you get there, however, you are faced with two problems:
1. Lack of drivers
2. Lack of applications
(And that is assuming you are writing your own file system, network stack and display manager, which are not trivial).

Unless you are Microsoft, Google or Apple, you cannot get hardware vendors to write drivers for your system, or application vendors to port their software. Even BlackBerry at its heyday had trouble with that, and QNX today, even though quite popular in certain segments with millions of deployments, is facing this challenge.
At that point, as a small OS vendor, your only recourse is to make your system compatible with other systems, at which point your slick, clean design breaks apart (or becomes horribly inefficient, which is what happened to most microkernel systems).


Applications are hard to write, sure. However that can be (mostly) solved by being compatible enough to some Linux setup. There are a number of popular UI and system abstraction layers that makes porting software easier but even those require some emulation of other systems.

Drivers can be "solved" by limiting hardware support. The base system is "easy", USB, PS/2, PCIe, SATA etc. can be written as if systems are actually compatible with documented (and semi-documented) interfaces and then be patched when a system is detected that have some quirk. Graphics drivers and network drivers are the two big problem areas IMHO.

Reply Score: 2

RE[5]: What happened to Photon?
by elahav on Mon 1st May 2017 11:14 UTC in reply to "RE[4]: What happened to Photon?"
elahav Member since:
2009-05-28


Applications are hard to write, sure. However that can be (mostly) solved by being compatible enough to some Linux setup. There are a number of popular UI and system abstraction layers that makes porting software easier but even those require some emulation of other systems.


That's true in theory, but fails in practice. The reason is that many applications are developed to observed behaviour rather than standards. A few examples from my own experience:

1. Linux over-commits memory. Consequently, many applications start by requesting huge amounts of memory. There is no problem on Linux so long as that memory is not used (at which point the application is killed with a SIGBUS). QNX has a strict no-over-commit policy for safety reasons, which means that these apps fail to initialize.
2. Skype bypasses the C library (or is statically linked, can't tell from the binary blob they ship), which means that it uses hard-coded kernel-call numbers. Implementing Linux compatibility in the C library doesn't help.
3. Many applications are buggy, but these bugs may be hidden on Linux for various reasons (e.g., different memory layout, Linux mutexes not checking for errors). I remember contacting the developers of a particular application that was writing outside of buffer bounds, but they refused to fix their code as it works on Android.

As a Linux user since 1999 (Red Hat 5.0) I really appreciate the irony of vendors content with their code running on Linux only.

Reply Score: 1

RE[6]: What happened to Photon?
by Megol on Mon 1st May 2017 13:33 UTC in reply to "RE[5]: What happened to Photon?"
Megol Member since:
2011-04-11


That's true in theory, but fails in practice. The reason is that many applications are developed to observed behaviour rather than standards. A few examples from my own experience:

1. Linux over-commits memory. Consequently, many applications start by requesting huge amounts of memory. There is no problem on Linux so long as that memory is not used (at which point the application is killed with a SIGBUS). QNX has a strict no-over-commit policy for safety reasons, which means that these apps fail to initialize.
2. Skype bypasses the C library (or is statically linked, can't tell from the binary blob they ship), which means that it uses hard-coded kernel-call numbers. Implementing Linux compatibility in the C library doesn't help.
3. Many applications are buggy, but these bugs may be hidden on Linux for various reasons (e.g., different memory layout, Linux mutexes not checking for errors). I remember contacting the developers of a particular application that was writing outside of buffer bounds, but they refused to fix their code as it works on Android.

As a Linux user since 1999 (Red Hat 5.0) I really appreciate the irony of vendors content with their code running on Linux only.


Yes, I didn't mean to suggest that porting "foreign" applications would be easy, just that is possible to get a reasonable subset of programs even into a smaller OS. As an example a web browser, a text editor and a compiler covers most of my use cases. Add RDP and/or VNC and the things I couldn't do would be reduced to watching movies, play games or watching demoscene demos.

Reply Score: 2

RE[4]: What happened to Photon?
by andreww591 on Sun 30th Apr 2017 23:50 UTC in reply to "RE[3]: What happened to Photon?"
andreww591 Member since:
2015-11-01


(And that is assuming you are writing your own file system, network stack and display manager, which are not trivial).


I'm planning to use either LKL (a "Linux kernel as a library" project) or the NetBSD rump kernel to provide a filesystem and network stack (actually, I hope to support both as options). The commands and libc will mostly be ported from FreeBSD. Initially I'll use X11 as the window system, although I'd like to replace it with a lightweight compositing window system of my own design.


At that point, as a small OS vendor, your only recourse is to make your system compatible with other systems, at which point your slick, clean design breaks apart (or becomes horribly inefficient, which is what happened to most microkernel systems).


UX/RT will be a natively Unix-like OS, so it won't really have to compromise much to be Linux-compatible. It will natively implement a lot of Linux specific APIs like signalfd, inotify, etc. even without the Linux compatibility layer (generally such APIs will be implemented in terms of special files like basically everything else in UX/RT). The only place where UX/RT won't be compatible with Linux user-mode programs is with programs that log in users or manage sessions. As far as I can see, the only place I'll have to make anything resembling a significant compromise will be to implement a hook that dynamically replaces Linux system call traps with function calls.


Which entity checks permissions has always been an interesting topic in the design of microkernels. As you mention, in QNX this is mostly done by the server, though QNX 7 also has channel abilities to prevent you from connecting to particular servers.
The alternative, which you suggest, has the major disadvantage that another entity (either the kernel or an external path manager) needs to mirror all nodes provided by all servers (and, in particular, all files and directories in all file systems) in order to enforce permission checks (which also makes it extremely hard to dynamically mount and unmount remote file systems). In QNX, the path manager is oblivious of any nodes other than the mount points of the various servers.
Neither solution is perfect...


UX/RT will implement both push and pull APIs for exporting directories to the process server. There will also be a hook to allow external processes to be notified when a directory is accessed to allow for automounting. UX/RT will use in-memory per-process ACLs (with the possibility of specifying fallback to filesystem permissions for groups of files) rather than the traditional Unix all-or-nothing model, so centralizing security in the kernel and process server will probably be the best way to do things.

Edited 2017-05-01 00:06 UTC

Reply Score: 1

Genode and Rumpkernel
by cybergorf on Sun 30th Apr 2017 18:38 UTC in reply to "RE[2]: What happened to Photon?"
cybergorf Member since:
2008-06-30

. Linux binary compatibility will be a top priority, and that should mostly solve the problem of application support. Driver support will also mostly be taken care of by Linux compatibility (there are already a couple of "Linux kernel as a library" projects that should be possible to use to provide device, network, and disk filesystem drivers). Hopefully the Linux application and driver support should make it at least somewhat successful as an alternative OS.


I guess you are already aware of the genode-projekt. Just in case:
http://genode.org

They have done some pretty work to encapsulate linux drivers to be used as user-level citizens on microkernels.
But in my opinion the rump-kernel/any-kernel (striped down user-level-bsd-kernels) project offers a better solution. It is also used by genode for filesystems ... but you could provide almost anything from audio over network to display by utilizing rump-kernels.
Advantage: since rump-kernel is a integrated part of NetBSD any new hardware supported by NetBSD will be automatically available as rump-kernel. And NetBSD has a much more stable driver-api than Linux does.
http://rumpkernel.org

hope to hear more from your project soon!

Reply Score: 1

RE: What happened to Photon?
by Moochman on Sat 29th Apr 2017 11:00 UTC in reply to "What happened to Photon?"
Moochman Member since:
2005-07-06

As stated in the article, QNX 7 is not backwards-compatible with earlier versions, so I guess that explains why he can't use Photon out-of-the-box. As for why Photon hasn't been further developed to run on QNX 7, I guess the answer is that the Photon widget library has been supplanted by Qt, and as the author mentions most embedded applications are fullscreen so there is no need for Photon's windowing capability.

This gets me thinking: It would be pretty cool to see a lightweight, fully cross-platform desktop environment based on "pure" Qt without the massive amount of dependencies KDE brings. In addition to serving platforms like QNX it could also be a hit on platforms like the Raspberry Pi or any other platforms that are "essentially embedded but desktop-capable".

Edited 2017-04-29 11:06 UTC

Reply Score: 2

RE[2]: What happened to Photon?
by rhy7s on Sat 29th Apr 2017 11:46 UTC in reply to "RE: What happened to Photon?"
rhy7s Member since:
2008-08-04

...

This gets me thinking: It would be pretty cool to see a lightweight, fully cross-platform desktop environment based on "pure" Qt without the massive amount of dependencies KDE brings. In addition to serving platforms like QNX it could also be a hit on platforms like the Raspberry Pi or any other platforms that are "essentially embedded but desktop-capable".

Something along the lines of LXQt http://lxqt.org/about/ ? (which is not fully cross platform but is becoming available in more Linux repos for the Pi e.g. https://packages.debian.org/search?suite=all&arch=armhf&searchon=nam... )

Reply Score: 2

RE[3]: What happened to Photon?
by Moochman on Sat 29th Apr 2017 11:57 UTC in reply to "RE[2]: What happened to Photon?"
Moochman Member since:
2005-07-06

Hey thanks, that really does look cool!! I'd of course heard of LXDE but wasn't really actively following its development and totally missed that they made a Qt port. I wonder if this might be usable on QNX. Going to write a comment on the article right now. ;)

Reply Score: 2

RE[3]: What happened to Photon?
by elahav on Sun 30th Apr 2017 11:01 UTC in reply to "RE[2]: What happened to Photon?"
elahav Member since:
2009-05-28

Porting LXQt was my first thought as well. Unfortunately, the code is heavily dependent on the X protocol, so that was a dead end.
Wayland looks more promising, as the protocol seems to be better separated from the display manager, and can hopefully be ported to work with QNX Screen.

Reply Score: 1

RE[2]: What happened to Photon?
by Intuition on Sat 29th Apr 2017 21:54 UTC in reply to "RE: What happened to Photon?"
Intuition Member since:
2013-05-28

Besides LXQt there's Lumina.

https://lumina-desktop.org/

Reply Score: 1

Hell yes!
by judgen on Sat 29th Apr 2017 11:50 UTC
judgen
Member since:
2006-07-12

Please make this happen!!!!!

Reply Score: 2

That explains it!
by Megol on Sat 29th Apr 2017 14:11 UTC
Megol
Member since:
2011-04-11

I wondered how they did provide backwards compatibility while extending the system to 64 bit, there were a number of quirks that would be hard to extend. Not doing it at all explains that.

If QNX hadn't decided to protect even basic information of their operating system from this release (forwards?) it'd be trivial to learn that. They used to have excellent documentation of their operating system and how to make use of it available on their website - now they require a login to even watch what documents are available...

Reply Score: 2

QNX Source Code
by Amanita on Sat 29th Apr 2017 19:32 UTC
Amanita
Member since:
2017-04-29

Does anybody happen to have a copy of the QNX source code from when it was publically available?

(under Apache license I think, and at least the kernel & basic libraries have definitely been there, they promised to add the Photon code and more drivers later but don't know if they actually did it. Just remember that I signed up for an account, but I was specifically looking for the GUI part at that time which wasn't available, so I forgot about it)

Would love to get a copy of it, being fascinated by low-level hacking (:

... and yeah, that floppy demo MarkHughes mentioned was pretty awesome. A fully functional web capable OS fitting in 1,44MB ... somehow I'm truly wondering what makes current Windows and OS X fill a whopping dual layer DVD (and even more, how on earth can applying updates to Win take so . much . time ...)

-x-x-x-

andreww591, do you have any material about your project online yet? This is not that unlike of what I am thinking about from time to time, but while I've actually toyed around with an own kernel 12 years or so ago, it is of course much too much for me and as a single person to really achieve something working. On the other side, I might be interested in participating in an open source collaboration, for fun and refresh my coding skills..

The genode project might have some good parts to borrow when it comes to drivers (they even have a HW accelerated Intel mesa GL) ... but overall it's truly frustrating that tech documentation about hardware is so scarce (if at all).

I am idealizing about a "hybrid" microkernel (VM, VFS, scheduling, messaging in the kernel, everything else outside..) renewing some of the very basic POSIX concepts like the pipes -attaching meta data to them, moving away from simple char[]s that get parsed etc. to something more object orientated.. same for /proc & /sys ...

Fine-grained permissions, no more sudo - maybe? But have to read up about these per-process namespaces you've mentioned.

Together with a decent debugger a microkernel should be able to make driver development much more painless if I'm not completely wrong - imagine writing a driver just like every other application, compile & run w/ breakpoints etc.. as a crash wouldn't hurt the system, just try to fix the code, run it again ...

Virtualization with the microkernel as a hypervisor could also open interesting abilities to easily(er) reverse engineer device drivers from Windows by capturing the communication between that certain hardware and the OS/driver?

Edited 2017-04-29 19:51 UTC

Reply Score: 1

RE: QNX Source Code
by andreww591 on Mon 1st May 2017 03:45 UTC in reply to "QNX Source Code"
andreww591 Member since:
2015-11-01

Does anybody happen to have a copy of the QNX source code from when it was publically available?

(under Apache license I think, and at least the kernel & basic libraries have definitely been there, they promised to add the Photon code and more drivers later but don't know if they actually did it. Just remember that I signed up for an account, but I was specifically looking for the GUI part at that time which wasn't available, so I forgot about it)

Would love to get a copy of it, being fascinated by low-level hacking (:


When QNX source was available, it was under a rather restrictive "shared source" type of license that only allowed non-commercial use. IIRC it didn't even allow redistribution. I think I did see a torrent of it a few years ago but I haven't looked recently and don't really want to download it because I don't want to be tainted by having read QNX source when I'm working on a similar OS.


andreww591, do you have any material about your project online yet? This is not that unlike of what I am thinking about from time to time, but while I've actually toyed around with an own kernel 12 years or so ago, it is of course much too much for me and as a single person to really achieve something working. On the other side, I might be interested in participating in an open source collaboration, for fun and refresh my coding skills..


I just opened a couple of GitLab projects for UX/RT and its bootloader. You're definitely welcome to contribute if you want (just don't contribute anything from the old QNX sources), although like I said before, I don't have much code yet (I've just pushed the boot image filesystem library and image builder, and will push the bootloader soon).

https://gitlab.com/uxrt/
https://gitlab.com/uxrt-bos/


The genode project might have some good parts to borrow when it comes to drivers (they even have a HW accelerated Intel mesa GL) ... but overall it's truly frustrating that tech documentation about hardware is so scarce (if at all).


I'd have to write some kind of abstraction layer since UX/RT will be completely different than Genode. Genode is a non-Unix strongly hierarchical pure capability OS with RPC as its IPC transport layer, whereas UX/RT will be a purely file-oriented and purely Unix-like OS , with unstructured streams as its IPC transport layer.


I am idealizing about a "hybrid" microkernel (VM, VFS, scheduling, messaging in the kernel, everything else outside..) renewing some of the very basic POSIX concepts like the pipes -attaching meta data to them, moving away from simple char[]s that get parsed etc. to something more object orientated.. same for /proc & /sys ...


That very much sounds like a Plan 9-style atypical monolithic kernel, not a microkernel.

And I don't think it's a good idea to put structured protocols at the filesystem or IPC transport layer. UX/RT will provide unstructured connection-oriented streams and shared memory (both implemented in terms of named files) as its only IPC mechanisms. However, one thing it will do to make implementing structured protocols on top of unstructured stream IPC easier will be to support message-boundary-preserving special files (normal Unix semantics have always allowed for reads to come up short on non-disk file descriptors, so this isn't much of a stretch).


Fine-grained permissions, no more sudo - maybe? But have to read up about these per-process namespaces you've mentioned.


That's exactly what I'm planning to do. UX/RT will implement per-process in-memory ACLs as its primary security model, and will provide no way to fully revert to traditional Unix all-or-nothing security (although it will be able to use permissions from the filesystem if a process's ACL specifies it for one or more groups of files).


Together with a decent debugger a microkernel should be able to make driver development much more painless if I'm not completely wrong - imagine writing a driver just like every other application, compile & run w/ breakpoints etc.. as a crash wouldn't hurt the system, just try to fix the code, run it again ...


Yeah, that's definitely one of the advantages microkernels have over monolithic kernels.


Virtualization with the microkernel as a hypervisor could also open interesting abilities to easily(er) reverse engineer device drivers from Windows by capturing the communication between that certain hardware and the OS/driver?


Possibly, although I don't think it's all that much easier to implement a VMM-level debugger on a microkernel.

Reply Score: 1

RPi
by Thom_Holwerda on Sat 29th Apr 2017 20:45 UTC
Thom_Holwerda
Member since:
2005-06-29

Release a damn ready-to-go image for the RPi - maybe even sell a preconfigured RPi in a nice QNX/BB case.

This shouldn't be hard.

Reply Score: 3

Photon
by kallisti5 on Sat 29th Apr 2017 21:52 UTC
kallisti5
Member since:
2009-09-08

Photon was one of the *awesome* things about QNX... too bad they let it rot. I have a 6.5 Hobby license, however with the sources this closed... I have enough projects that are open source to fill my time :-)

Reply Score: 1