7 ms·

this sounds like a really cool way to operate and it would be really interesting if you could expand on your experiences.

jacquesm 6y ago
I worked on a project that used QnX for large volume message transmission via custom telex interfaces. Millions of messages on a good Monday morning. Because I like my development machine to run the same OS as the servers I ended up using it for my daily driver for quite a few years. In the end I liked it so much that when Quantum Software dawdled on their 32 bit implementation that I wrote my own version of the OS. One really neat demo was 250 windows running the size of poststamps with a little bouncing line demo inside them. All still received their 'fair share' of time, all could still be moved around and expanded as though the machine was otherwise idle.
- mjcohen 6y ago
  About as good as the Amiga.
- kjs3 6y ago
  Would you have that OS you wrote up on github or anything, would you? Big fan of QNX; like to look at OS code.
  - jacquesm 6y ago
    Ok. see https://jacquesmattheij.com/task.cc https://jacquesmattheij.com/task.cc That's the scheduler. There are a lot of moving parts to running this code, I may make a little project out of restoring it to life under a VM at some point. Happy reading. Edit: reading it myself, wow, my English was cringe worthy back then. Moving to Canada certainly fixed that.
    - kjs3 6y ago
      Awesome. Thanks. FWIW, I think there's still a place for 32-bit OSes if you never port to 64-bit. Small devices, IoT, or this mc68030 thing I've been building. Lot's of opportunity for fun.
      - jacquesm 6y ago
        Sure, but if I'm going to spend that much effort I might as well make it future proof. The first iteration of that project cost me two years of my life, and that was when I was 27. To do this again today would be on a relative scale a much bigger investment in the time that remains.
- YarickR2 6y ago
  And what about IO ? What will you do when everything is stuck waiting for that spinning rust to position itself under the drive head ?
  - jacquesm 6y ago
    That's just another user process. So everything else will continue. You have to let go of your macro kernel mindset if you want to make sense of the timing in a micro kernel environment. Blocking threads is fine. Just make sure that you don't do that sort of stuff in your UI thread and you won't even realize there is such a thing as disk or network IO. Mouse, keyboard, screen. Those are the things that should run at high priority. Everything else can - quite literally - wait.
    - leguminous 6y ago
      > Mouse, keyboard, screen. Those are the things that should run at high priority. Everything else can - quite literally - wait. I might add audio to this list.
      - jacquesm 6y ago
        Ah yes, of course. Sorry, I wasn't thinking clearly, just had the usual UI loop and regular interaction with a computer in mind, you are 100% right, audio should have a very high priority. Nothing more annoying than dropouts. Incidentally, the way most OSs deal with that is by having very large audio buffers which in turn will give you terrible latency. On a hard real time OS you could reduce the size of those buffers quite a bit because you can guarantee they are filled (and emptied) regularly.
        amluto 6y ago
        This is not straightforwardly true. Using small buffers and real-time scheduling works, but it gives terrible power efficiency on a modern high-performance CPU. What you actually want is a scheme with large buffers that can throw out those buffers if something requiring low latency happens.

jacquesm 6y ago

I worked on a project that used QnX for large volume message transmission via custom telex interfaces. Millions of messages on a good Monday morning. Because I like my development machine to run the same OS as the servers I ended up using it for my daily driver for quite a few years. In the end I liked it so much that when Quantum Software dawdled on their 32 bit implementation that I wrote my own version of the OS. One really neat demo was 250 windows running the size of poststamps with a little bouncing line demo inside them. All still received their 'fair share' of time, all could still be moved around and expanded as though the machine was otherwise idle.

mjcohen 6y ago
About as good as the Amiga.
kjs3 6y ago
Would you have that OS you wrote up on github or anything, would you? Big fan of QNX; like to look at OS code.
- jacquesm 6y ago
  Ok. see https://jacquesmattheij.com/task.cc https://jacquesmattheij.com/task.cc That's the scheduler. There are a lot of moving parts to running this code, I may make a little project out of restoring it to life under a VM at some point. Happy reading. Edit: reading it myself, wow, my English was cringe worthy back then. Moving to Canada certainly fixed that.
  - kjs3 6y ago
    Awesome. Thanks. FWIW, I think there's still a place for 32-bit OSes if you never port to 64-bit. Small devices, IoT, or this mc68030 thing I've been building. Lot's of opportunity for fun.
    - jacquesm 6y ago
      Sure, but if I'm going to spend that much effort I might as well make it future proof. The first iteration of that project cost me two years of my life, and that was when I was 27. To do this again today would be on a relative scale a much bigger investment in the time that remains.
YarickR2 6y ago
And what about IO ? What will you do when everything is stuck waiting for that spinning rust to position itself under the drive head ?
- jacquesm 6y ago
  That's just another user process. So everything else will continue. You have to let go of your macro kernel mindset if you want to make sense of the timing in a micro kernel environment. Blocking threads is fine. Just make sure that you don't do that sort of stuff in your UI thread and you won't even realize there is such a thing as disk or network IO. Mouse, keyboard, screen. Those are the things that should run at high priority. Everything else can - quite literally - wait.
  - leguminous 6y ago
    > Mouse, keyboard, screen. Those are the things that should run at high priority. Everything else can - quite literally - wait. I might add audio to this list.
    - jacquesm 6y ago
      Ah yes, of course. Sorry, I wasn't thinking clearly, just had the usual UI loop and regular interaction with a computer in mind, you are 100% right, audio should have a very high priority. Nothing more annoying than dropouts. Incidentally, the way most OSs deal with that is by having very large audio buffers which in turn will give you terrible latency. On a hard real time OS you could reduce the size of those buffers quite a bit because you can guarantee they are filled (and emptied) regularly.
      - amluto 6y ago
        This is not straightforwardly true. Using small buffers and real-time scheduling works, but it gives terrible power efficiency on a modern high-performance CPU. What you actually want is a scheme with large buffers that can throw out those buffers if something requiring low latency happens.