I love reading all these new advancements no operating systems. I can't help but fear that we will be stuck for a long time with the same old "posix compliant unix like operating systems" though.
Perhaps, but consider the number of features making their way into Linux that are not POSIX, whose man pages specifically mention this.
My favourite example is inotify with epoll. When I wrote my first server, I used select(), because that’s what we had. It worked, well enough, but so much of the coding around it was trying to quickly, very quickly, detect edge cases and odd errors, then dispatch the right handler. Quickly very quickly because other events could be coming in and could be lost.
This past February I wrote an application to manage incoming files in a secure gateway, having to be mindful of disk space and of pushing them across the one way optical link as quickly and efficiently as possible. (With a few other requirements, such as transfer priorities, etc.)
My initial implementation using inotify and epoll contained placeholder code for dealing with those times my app would miss notifications. Given my decades old experience with select, etc., this was a reasonable direction.
I never added that code. inotify with epoll worked so well and so reliably, it was never needed. I was stunned at how well it worked.
Linux continues to add features and to support POSIX. The trick for system and application developers now is to know whether you need portability more than you need the performance, efficiency, and/or other advanced capabilities of these new, non-POSIX approaches.
An older presentation on this at USENIX (2016): https://www.usenix.org/conference/osdi16/technical-sessions/...
And here's the project page (at Yale): https://flint.cs.yale.edu/certikos/
I love reading all these new advancements no operating systems. I can't help but fear that we will be stuck for a long time with the same old "posix compliant unix like operating systems" though.
Perhaps, but consider the number of features making their way into Linux that are not POSIX, whose man pages specifically mention this.
My favourite example is inotify with epoll. When I wrote my first server, I used select(), because that’s what we had. It worked, well enough, but so much of the coding around it was trying to quickly, very quickly, detect edge cases and odd errors, then dispatch the right handler. Quickly very quickly because other events could be coming in and could be lost.
This past February I wrote an application to manage incoming files in a secure gateway, having to be mindful of disk space and of pushing them across the one way optical link as quickly and efficiently as possible. (With a few other requirements, such as transfer priorities, etc.)
My initial implementation using inotify and epoll contained placeholder code for dealing with those times my app would miss notifications. Given my decades old experience with select, etc., this was a reasonable direction.
I never added that code. inotify with epoll worked so well and so reliably, it was never needed. I was stunned at how well it worked.
Linux continues to add features and to support POSIX. The trick for system and application developers now is to know whether you need portability more than you need the performance, efficiency, and/or other advanced capabilities of these new, non-POSIX approaches.
Nice, so this basically overcomes one of the main limitations of SEL4 etc?
Would programming in DrRacket running on seL4 microkernel allow better debugability and control?
What are these seL4 limitations?
As I understand it, the multicore version was never verified. I could be out of date on that though.