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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2563 invoked from network); 24 Jan 2021 22:54:27 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 24 Jan 2021 22:54:27 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id D35C39C73D; Mon, 25 Jan 2021 08:54:26 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id F2DDD9C641; Mon, 25 Jan 2021 08:53:55 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Q+xflhk1"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 49AA69C641; Mon, 25 Jan 2021 08:53:54 +1000 (AEST) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) by minnie.tuhs.org (Postfix) with ESMTPS id B46D49C5FD for ; Mon, 25 Jan 2021 08:53:53 +1000 (AEST) Received: by mail-oi1-f175.google.com with SMTP id h6so11502877oie.5 for ; Sun, 24 Jan 2021 14:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tYmG7HEVmN+cvWVIKpbQClwlGEjSpINTxUdiNaXAAPg=; b=Q+xflhk12VMahYWZIlBRHAT6/VfF2NQqd6J5Bc/X/eGI1XJj9QBKuNpmLAwNDnqx26 RuIbQEAjhmiWyjbWBScwJxIM5sF9qpqKPnr+VMHlB16Q+katZ1hoepMPPvoSU3DaxIXw 0zmQGOyzP5grzulfAxl2ZND3Oq90IVHR5gV1q2bNgkMikG5BiU/F3UeyqOAUx5TxOFk2 LYqvmelsTU9lpWuHzz7W/gsh1t0KqUzgHKK6mca2iBdB13MQEuMfkDI+7eZ3feZsavFt ZaZHd6XQhBpbUXOX0jjTTf2Qr3/9fj6oSqgEqctQFwIzQr3i5svz7sk307lLzu7EGUlF YQMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tYmG7HEVmN+cvWVIKpbQClwlGEjSpINTxUdiNaXAAPg=; b=KdUrU3xY/y78E99ehDTmuq3FtUUri3xU+v6wyr2JYRJtgD70qF8p5MyXIxhLQYOnZX aI+w2GUsIxmPXrr5hpw3+Y5lkyZQwo7TSD70aQT7JF13DT8WUULohkD5EsIfBfSe6t6i osxKb46UKIeMh/afJfKra3uiFHPjmv7LawXtTydgvX+/T8xzX+K925uXFtynaNou6c+n hS6dwQlU5j67E1VJ/a4bIMwiq0XPQEvPjwEEBt/mtc9+D2+upp+Pvq2+Ul8EbDMd+Mrh Nv6J4pxNNZdpGxWr7Fcb4d2zpcQQHMOXIrkxMTojZy3pVwY3ZGS9sepnAcCeuRu+yLHl pKew== X-Gm-Message-State: AOAM530i9UogZ00tXsL13FsORPNeQmDfQfrPBMMBgHaB4JOif8UO+8NQ CMmnmessOuZmTVhl6s++xl/z4nb7nP2V2NKImZoKfqhLT+c= X-Google-Smtp-Source: ABdhPJzDAJI4Qa16q5MrVNsKEw0znB0QEV0vtkTUr9IpKO1It1+dkjhh7+sRFZwHu3FZMTr+hoL6Gb0KCXAs6n/cyA8= X-Received: by 2002:aca:210f:: with SMTP id 15mr1569443oiz.174.1611528833009; Sun, 24 Jan 2021 14:53:53 -0800 (PST) MIME-Version: 1.0 References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> In-Reply-To: <20210124212525.GJ21030@mcvoy.com> From: Dan Cross Date: Sun, 24 Jan 2021 17:53:16 -0500 Message-ID: To: Larry McVoy Content-Type: multipart/alternative; boundary="000000000000a30c8205b9ad4b5a" Subject: Re: [TUHS] tangential unix question: whatever happened to NeWS? 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 main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000a30c8205b9ad4b5a Content-Type: text/plain; charset="UTF-8" On Sun, Jan 24, 2021 at 4:25 PM Larry McVoy wrote: > On Sun, Jan 24, 2021 at 01:14:34PM -0800, Jon Steinhart wrote: > > So I never liked Apollos much. What I was referring to was Apollo's > claim > > that their token-ring network performed better for large numbers of > nodes. > > And they were correct. However, they didn't consider the eventually > > invention of switches that solved the problem. > > The network performance of the cluster of Apollos we had was awful. > I don't know anything about how you set that up, never liked token rings, > maybe it is possible to set it up wrong, I dunno. All I know was network > performance was awful on the Apollos. > Interestingly, descendents of the Apollo RPC system live on in windows, and if I recall correctly, got there via the DCE/RPC library, largely contributed by Apollo. Some good judges have said that, on technical merits, the RPC layer was superior to ONC RPC, though I never used an Apollo machine to really know. I remember working at a startup in late 1999/early 2000 that had built some hokey network daemon to track people logged into their website; this thing crashed all the time, was slow, and generally not well implemented. It occurred to me that much of the complexity of dealing with it was in the level of abstraction for the network being too low: it ran on a Sun, so reimplemented it on top of ONC/RPC with XDR for architecture independence (most of the web servers were Intel machines). The new code was a sixth of the size of what I started with, it was simpler and easier to reason about, used less memory, was significantly faster, etc. The lesson is that the right abstractions matter. I further remember when I got to Google and saw protobuf for the first time being a little confused. "Why didn't you just use XDR? It's an Internet standard and there's an RFC defining it, and it's implemented essentially everywhere. Why do something new?" The response was very much along the lines of, "ho ho; this is Google, kid. We know what we're doing." Apparently, the variable-length encoding for integers was considered particularly important at the time, an argument I never really bought into. *shrug* It's a statistically valid sampling of one case :-) > I can totally believe that their workstations were slow and the software environment was a bummer. The interesting thing about all of this graphics stuff (and to tie it back to TUHS) is that none of these things ever struck me as particularly Unix-y in nature. X in particular doesn't seem like it composes nicely with anything else, and in many ways, Unix from the perspective of a user is all about composition from smaller parts. But X is this big, monolithic thing that you kind of bolted on the side. For example, it certainly doesn't integrate with, say, the permissions model. I wonder if these seeming impedance mismatches are because pretty much being all of this stuff invented as folks went along. - Dan C. --000000000000a30c8205b9ad4b5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jan 24, 2021 at 4:25 PM Larry McV= oy <lm@mcvoy.com> wrote:
On Sun, Jan 24, 2021 at 01:14:34PM -0800, Jon Steinhart wrote:
> So I never liked Apollos much.=C2=A0 What I was referring to was Apoll= o's claim
> that their token-ring network performed better for large numbers of no= des.
> And they were correct.=C2=A0 However, they didn't consider the eve= ntually
> invention of switches that solved the problem.

The network performance of the cluster of Apollos we had was awful.
I don't know anything about how you set that up, never liked token ring= s,
maybe it is possible to set it up wrong, I dunno.=C2=A0 All I know was netw= ork
performance was awful on the Apollos.

I= nterestingly, descendents of the Apollo RPC system live on in windows, and = if I recall correctly, got there via the DCE/RPC library,=C2=A0largely cont= ributed by Apollo. Some good judges have said that, on technical merits, th= e RPC layer was superior to ONC RPC, though I never used an Apollo machine = to really know.

I remember working at a startup in= late 1999/early 2000 that had built some hokey network daemon to track peo= ple logged into their website; this thing crashed all the time, was slow, a= nd generally not well implemented. It occurred to me that much of the compl= exity of dealing with it was in the level of abstraction for the network be= ing too low: it ran on a Sun, so reimplemented it on top of ONC/RPC with XD= R for architecture independence (most of the web servers were Intel machine= s). The new code was a sixth of the size of what I started with, it was sim= pler and easier to reason about, used less memory, was significantly faster= , etc. The lesson is that the right abstractions matter.

I further remember when I got to Google and saw protobuf for the fir= st time being a little confused. "Why didn't you just use XDR? It&= #39;s an Internet standard and there's an RFC defining it, and it's= implemented essentially everywhere. Why do something new?" The respon= se was very much along the lines of, "ho ho; this is Google, kid. We k= now what we're doing." Apparently, the variable-length encoding fo= r integers was considered particularly important at the time, an argument I= never really bought into. *shrug*

It's a statistically valid sampling of one case :-)

I can totally believe that their workstations were slow an= d the software environment was a bummer.

The inter= esting thing about all of this graphics stuff (and to tie it back to TUHS) = is that none of these things ever struck me as particularly=C2=A0Unix-y in = nature. X in particular doesn't seem like it composes nicely with anyth= ing else, and in many ways, Unix from the perspective of a user is all abou= t composition from smaller parts. But X is this big, monolithic thing that = you kind of bolted on the side. For example, it certainly doesn't integ= rate with, say, the permissions model.

I wonder if= these seeming impedance mismatches are because pretty much being all of th= is stuff invented as folks went along.

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 - Dan C.

--000000000000a30c8205b9ad4b5a--