From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27661 invoked from network); 22 Jul 2020 03:14:47 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 22 Jul 2020 03:14:47 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 6FD469C8FA; Wed, 22 Jul 2020 13:14:46 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 12F5E9C8C3; Wed, 22 Jul 2020 13:14:02 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id F23879C8C3; Wed, 22 Jul 2020 13:13:29 +1000 (AEST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by minnie.tuhs.org (Postfix) with ESMTPS id F41CE93D09 for ; Wed, 22 Jul 2020 13:13:27 +1000 (AEST) Received: from callcc.thunk.org (pool-96-230-252-158.bstnma.fios.verizon.net [96.230.252.158]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06M3DDVK030862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jul 2020 23:13:14 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 4107D420304; Tue, 21 Jul 2020 23:13:13 -0400 (EDT) Date: Tue, 21 Jul 2020 23:13:13 -0400 From: tytso@mit.edu To: Larry McVoy Message-ID: <20200722031313.GC1536749@mit.edu> References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720114957.GL26294@mcvoy.com> <20200721010411.GS26294@mcvoy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200721010411.GS26294@mcvoy.com> Subject: Re: [TUHS] A/UX [was Linux is on-topic] X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" 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 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