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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4667 invoked from network); 16 Feb 2021 12:29:59 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 16 Feb 2021 12:29:59 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id B0E549B958; Tue, 16 Feb 2021 22:29:56 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 05E7A94F19; Tue, 16 Feb 2021 22:28:46 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=cfcl.com header.i=@cfcl.com header.b="IFGc0Baw"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 1728294F19; Tue, 16 Feb 2021 22:26:15 +1000 (AEST) Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by minnie.tuhs.org (Postfix) with ESMTPS id AE19594F18 for ; Tue, 16 Feb 2021 22:26:13 +1000 (AEST) Received: by mail-pg1-f177.google.com with SMTP id o63so6116252pgo.6 for ; Tue, 16 Feb 2021 04:26:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cfcl.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=UK3zEtITDxtjHFxh2cLH5IhXPKvEUBeBi8kbPYRYqwU=; b=IFGc0BawAwMVu99+SIkwB2caopcQlCJ+j9rfUUnzCQx0qor56Yz1lgwzfnN0KYiAKo pbptauzetLc8iLIR68tW52gt/90xQlOkBVwU05AOncSE+Dy6KLJUoaywaXDDHIiyBk6m 6s9BF44uNhiyv4halddeZPMByeH6C2JGyermXhdy7sSKgJ44rhzgeiFF2u8uxOx+6tu7 XTYXQDtVV/FH+BfTDZwNKA4Pj7+6tk5my3rGl7LJKW9qxzr8j+aKq2LE6B1E1fo+8Zxz liurPq/VPOeCc9DbVOMXB64LBPwwrtqHePrWI3ihBLc2CwIHzsXeRzR5qqiJmuXqXVi5 i4EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=UK3zEtITDxtjHFxh2cLH5IhXPKvEUBeBi8kbPYRYqwU=; b=qWuGuCW72zjWtBBKnu5QD4lTjSCfaedPjUQP66QWhcYwTTJuOmtFMWjdogBKjNVHtW rHuUquZg6alVzreNu2BauL1qDYFq0l8WYxWSRrARQcaiES+2z0bFlYJuXKDWI2aDjbA/ BNPfbaQOOdTJHFOEK5md95XDoFSlh1iPYQt52U7ULF3L9tPgjfDSiDgs3R1crmBvpcXo hr3YZYQVgRVIL/FMwSPi52vpvJpODsMgJFjXbYoFRj41oUMfch3NvBDy55ryLSi3hfp/ bqfOgrZTvY8CAntI0NMlxnQColzJfFkvoOOBTUEpgHL23SUShAsnP0QLo6XhvcgAyiRi pliA== X-Gm-Message-State: AOAM531aN2pJlsUUs+Kx6w4lxgFdLAIV2nGRCIiDd1d8sxfrlnv7JRx7 6kAczmyKrXFmQx4D+XVmIQhVelTKjR2A3g== X-Google-Smtp-Source: ABdhPJz8cwNEv1APmyOnn7sizrse6tmLZHQkaSnVFE336z5E3+BrvzeX2J8q82SViVwAoKUpCkNtbw== X-Received: by 2002:a62:804a:0:b029:1e7:d747:de3 with SMTP id j71-20020a62804a0000b02901e7d7470de3mr19450023pfd.38.1613478372970; Tue, 16 Feb 2021 04:26:12 -0800 (PST) Received: from spot.hitronhub.home (24-113-88-45.wavecable.com. [24.113.88.45]) by smtp.gmail.com with ESMTPSA id f3sm21148798pfe.25.2021.02.16.04.26.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Feb 2021 04:26:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Rich Morin In-Reply-To: <202102151956.11FJuRIh3079869@darkstar.fourwinds.com> Date: Tue, 16 Feb 2021 04:26:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <202102151956.11FJuRIh3079869@darkstar.fourwinds.com> To: TUHS main list X-Mailer: Apple Mail (2.3608.120.23.2.4) Subject: Re: [TUHS] Abstractions 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > On Feb 15, 2021, at 11:56, Jon Steinhart wrote: >=20 > Was thinking about our recent discussion about system call bloat and = such. > Seemed to me that there was some argument that it was needed in order = to > support modern needs. As I tried to say, I think that a good part of = the > bloat stemmed from we-need-to-add-this-to-support-that thinking = instead > of what's-the-best-way-to-extend-the-system-to-support-this-need = thinking. >=20 > So if y'all are up for it, I'd like to have a discussion on what = abstractions > would be appropriate in order to meet modern needs. Any takers? The folks behind the Nerves Project (https://www.nerves-project.org) = have done some serious thinking about this question, albeit mostly = confined to the IoT space. They have also written (and distribute) some = nifty implementation code. I won't try to cover all of their work here, but some high points = include: - automated build and cross-compilation of entire Linux-based systems - automated distribution of (and fallbacks for) updated system code - separation of code and data using read-only and read/write file = systems - support for multiple target platforms (e.g., processors, boards) - Erlang-style supervision trees (via Elixir) for critical services, = etc. - extremely rapid boot times for the resulting (Linux-based) systems For more information, check out their web site, watch some = presentations, and/or (gasp!) try out the code... -r =20=