[TUHS] A/UX [was Linux is on-topic]

[tytso at mit.edu]

On Mon, Jul 20, 2020 at 06:04:11PM -0700, Larry McVoy wrote:
> On Mon, Jul 20, 2020 at 05:11:48PM -0500, Ed Carp wrote:
> > On 7/20/20, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > > Clem should pay attention, in my opinion, this is how you do Unix and
> > > real time.  Because Unix is time sharing and throughput, that is the
> > > opposite of what real time is.  Wedging real time into Unix is a mistake.
> > 
> > Agreed.
> 
> So many people get this wrong, they want to make "real time" in Unix "good
> enough" and it messes with everything.  Victor's idea was awesome.
> 
> And you know what sucks?  I was on the Usenix review committee and I gave
> it 2 thumbs up but someone else, looking at you, Rob, said it was not 
> interesting because the real time kernel wasn't POSIX.  Even though the
> real time kernel had pipes, signals, and shared memory with Linux.
> 
> He was a bigger deal than me so it didn't get published.
> 
> I love the Rob in question, not Pike, but this was one of the most bone
> headed calls I've ever seen him make.  The world needed to see this.

Never fear, Victor's work got published in a number of Linux
conference, so it wasn't totally buried.

> Wind River bought it and buried it because it competed with their stuff
> that was nowhere near as good.

I can't get into the mind of Wind River. but having worked on a
commercial real-time extension to Linux, and having gotten a IBM
Systems Journal publication[1] out of it, I have a slightly different
perspective.

[1] https://ieeexplore.ieee.org/document/5386551

The issue is that there aren't that many good real-time programmers
Tavailable.  Furthermore, many real-time applications need to do a lot
more than data acquisition, so having access to POSIX API's in the
real time task is very attractive.  Sure, you can try to interchange
information between the real-time task and the POSIX task, but that's
a lot more complicated, and that's where the "not enough real-time
programmers" rears its head again.

This is even worse if you are working in a military application, since
small population of "can program real-time programmers" is further
reduced by "can get a security clearance".

Fortunately, with modern, fast CPU's, it's possible to do real-time
via brute force, and as it turns out, there are a very large number ofJ
real-time tasks which can deal with real-time latency that are tens of
milliseconds, at which point you even use real-time Java with a
real-time garbage collector running on a real-time Linux.  And that's
what Raytheon and the US Navy chose to use on their Zumwalt Class
destroyers, and that's how I and my team got the IBM Systems Journal
publication.   :-)

Sure, there will be some number of real-time task which needs
single-digit millisecond real-time guarantees --- in which case you
can write it in C using Real-time Linux.  And for those really cases
where you need latencies which are in the tens of microsecnds; then
yeah, at that point you might need specialized OS's.  But the cases
where you need fast, hard real-time is pretty rare compared to those
cases where real-time Java is sufficient.

Cheers,

					- Ted