From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 83554a6c for ; Sat, 18 Jan 2020 07:30:42 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 4D66C9C106; Sat, 18 Jan 2020 17:30:41 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 506689BDD8; Sat, 18 Jan 2020 17:30:16 +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="oNTpt6to"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 09D589C0F7; Sat, 18 Jan 2020 17:30:14 +1000 (AEST) Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) by minnie.tuhs.org (Postfix) with ESMTPS id 881CA9BDD8 for ; Sat, 18 Jan 2020 17:30:10 +1000 (AEST) Received: by mail-il1-f175.google.com with SMTP id t17so23195724ilm.13 for ; Fri, 17 Jan 2020 23:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FyC+8MJC0Gk0neR10VuNXiMC08VIiaxdDpI4KhZyV9I=; b=oNTpt6tocELQJsfgnfbsPatfgIAmORPQkqQjr3+Hzk7+XYV1Qv7oMcfD4umxnPWv2j HGxoPcB/XTARnFfqVWIxR7lp0kYuoB8t5ahroqLCatHCQgB/j8To6Ro0ETiTCSoOIRv3 LPB2lRqG4W+55Kqa6HaGWswCnz3Lp7xQeJIOwFAKTUgXtkXhZqedaGUhgkVuikshAdcD KpR+E6qWcihiN/RNqDrrx39Vj/79flhh/Ie8vYXm6Y2bsHz3lUclDb/xz6WSj8A7gUfV +CvAIuV+W86BIfxWt9XkITMV8CiBmRa5NkHz2GpdSo9km8S8okS4hCSDhoiLSk8gO0o8 CHXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FyC+8MJC0Gk0neR10VuNXiMC08VIiaxdDpI4KhZyV9I=; b=RWnol0q5dXU19anjUm4ZoTBhQYR1Y4r3fCjuqngY3u9qie6GSA0APyritjZfTE5VPe lUBbGi05FRHSqE0FLxvolMg8wINCTI1ELQAbuy4btS6SHBTmTJGlEb9P9Rn1XK9GpIXb l4zOpa29/A4MH2hv21uc5tkYUlwUjJKlaSV0iABn3DeHjI8IOjYlitzv3+rx+Hf8tUWq dbs9sjj3/rR4QJW5EXM+Q7sLazQ7OWDs+U9oPn4UiARboEWWAnra5P3ReK5TqBF6RYEP 4u0nlOVI4k8epJkEMLwxXGl5zHAkcKYczLdDxsthF8YzEakGP4zBePkyqr1ECwPDLnf/ mCEw== X-Gm-Message-State: APjAAAW7tYhGOsdrznkXQWAxZ3UUshJutBRO91ED348D1bL1uoVDnPwK lAhnl02Y5UCs+myEYTtb8lylsMnWQCxW5FKKgIHc1g== X-Google-Smtp-Source: APXvYqzCk4aLlH1xI8vAlSK+t6ZamQeEO4FjMOtTSfgmuIfOuI+190WNj4fD9hUyTIEonOQGo9cWaL9G5mN4PuF2WBg= X-Received: by 2002:a92:1d11:: with SMTP id d17mr2112261ild.86.1579332609814; Fri, 17 Jan 2020 23:30:09 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ac0:f201:0:0:0:0:0 with HTTP; Fri, 17 Jan 2020 23:30:09 -0800 (PST) In-Reply-To: References: From: Andrew Warkentin Date: Sat, 18 Jan 2020 00:30:09 -0700 Message-ID: To: coff@minnie.tuhs.org Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] [TUHS -> COFF] Distributed systems, was: On the origins of Linux - "an academic question" 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: The Eunuchs Historic Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 1/17/20, Rob Pike wrote: > I am convinced that large-scale modern compute centers would be run very > differently, with fewer or at least lesser problems, if they were treated > as a single system rather than as a bunch of single-user computers ssh'ed > together. > > But history had other ideas. > [moving to COFF since this isn't specific to historic Unix] For applications (or groups of related applications) that are already distributed across multiple machines I'd say "cluster as a single system" definitely makes sense, but I still stand by what I said earlier about it not being relevant for things like workstations, or for server applications that are run on a single machine. I think clustering should be an optional subsystem, rather than something that is deeply integrated into the core of an OS. With an OS that has enough extensibiity, it should be possible to have an optional clustering subsystem without making it feel like an afterthought. That is what I am planning to do in UX/RT, the OS that I am writing. The "core supervisor" (seL4 microkernel + process server + low-level system library) will lack any built-in network support and will just have support for local file servers using microkernel IPC. The network stack, 9P client filesystem, 9P server, and clustering subsystem will all be separate regular processes. The 9P server will use regular read()/write()-like APIs rather than any special hooks (there will be read()/write()-like APIs that expose the message registers and shared buffer to make this more efficient), and similarly the 9P client filesystem will use the normal API for local filesystem servers (which will also use read()/write() to send messages). The clustering subsystem will work by intercepting process API calls and forwarding them to either the local process server or to a remote instance as appropriate. Since UX/RT will go even further than Plan 9 with its file-oriented architecture and make process APIs file-oriented, this will be transparent to applications. Basically, the way that the file-oriented process API will work is that every process will have a special "process server connection" file descriptor that carries all process server API calls over a minimalist form of RPC, and it will be possible to redirect this to an intermediary at process startup (of course, this redirection will be inherited by child processes automatically).