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,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5247 invoked from network); 23 Feb 2021 03:32:20 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 23 Feb 2021 03:32:20 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id ECE179CA90; Tue, 23 Feb 2021 13:32:16 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id E0CAC93D39; Tue, 23 Feb 2021 13:31:56 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="DYalRF1t"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 801A493D39; Tue, 23 Feb 2021 13:31:53 +1000 (AEST) Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) by minnie.tuhs.org (Postfix) with ESMTPS id 7A06993D32 for ; Tue, 23 Feb 2021 13:31:51 +1000 (AEST) Received: by mail-il1-f180.google.com with SMTP id d5so3969766iln.6 for ; Mon, 22 Feb 2021 19:31:51 -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; bh=Zy6GHpumUx++pOsteFJMfLE4NZqkiPHWieH0mg1gxnk=; b=DYalRF1tfe8wkUv535NjhR4IEwzoyir+t9COH+kOXOaKnV77oBFm1K9frJ2EbMfi1a abhJCxt2UL8+Ai27f/AK5sbVEb3++6Hz1/XxHmzXLIwe10dW1Cs4TGZZxmWgW9M2QdWm pPlEVt/OQjS4DO38wbBnTBSk0fjRZ8+TTfn0agJbKu5VO02R0EmbWhT6Prdp444krIMD wjRvcBxYbHrfPqXL5Pb2md5JIoIOGqO6LBsdkOz5CDbxzewfPScxMo8uGrpEG9FhYY7G d4XinO4oSLWhFERX0UkIOzINoqFEF44MXfGrbPh9eslRyHedxVRUICEERb+57K+eGH+D SI6A== 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; bh=Zy6GHpumUx++pOsteFJMfLE4NZqkiPHWieH0mg1gxnk=; b=NxP9iB1FEJ/I4Q3xDLbLpiWLGaPsWpESdJzo5ZK9Ifdb5SX5TVTnm4xb99QMb6Fiio ciP3JjgvZE0vYifBfMoMhNlOATAm36UaCaJF2C0CilF2xy6TKhtGikj8PptD2PD2STfo NGP6yB8ptqq+puVoR3HKxY8kwyDNgSJKfqfsTnerxiKPlxaIalcZ7KwuWgKg32yoSs8i D0OSe0biUXiTqXlWL39wPjRBI3fxY3twJbo4Wbv+FhyFeZVO4Ogto4BtRqCitGgAj23h FdPIX8EB5fc/W9AP0wuTn1vM6F5uHsw71mgG+t8TmQZv1XU6EV1TL0RTkirlPOlh1aFk ILTQ== X-Gm-Message-State: AOAM533vQEXBC6g6bISSH345TgC8fD50yUokeTqPDEsvX7AJkaSLwyel iUIccSHBZBWW1Z17olsSIH7KRd9Plai1SCFIs8umU7G+ X-Google-Smtp-Source: ABdhPJw+tPkEwlmUYTDaKSu8O4PTmYbpS9DjkdnRsgwseOOVf0eAeijWGk4IuTCv1L9cSLzgBU2cc8bZZ7OURDYVeus= X-Received: by 2002:a92:cc49:: with SMTP id t9mr9757108ilq.86.1614051110615; Mon, 22 Feb 2021 19:31:50 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ac0:eda8:0:0:0:0:0 with HTTP; Mon, 22 Feb 2021 19:31:49 -0800 (PST) In-Reply-To: References: From: Andrew Warkentin Date: Mon, 22 Feb 2021 20:31:49 -0700 Message-ID: To: tuhs@tuhs.org Content-Type: text/plain; charset="UTF-8" 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 2/21/21, Steve Nickolas wrote: > > While I've been stuck regarding bringing up a kernel, C compiler and libc > all together, (keeping in mind my desire to avoid gcc and glibc for the > project) the conceptual distribution I've been working on for some time > uses more or less the same abstraction as the BSDs, with distinct /bin and > /sbin vs. /usr/bin and /usr/sbin as I personally believe it should be, > that the stuff in /bin should be enough to bring up and/or run diagnostics > on a system, and everything else go in /usr. > I don't see much of a point in maintaining the separation these days. /bin and /usr/bin were originally separated because it wasn't possible to fit everything on one disk, and (AFAIK) the separation was mostly maintained after that to reduce the chance of filesystem corruption rendering the system unbootable (which is much less of a problem nowadays because of journalled and log-structured filesystems). Under UX/RT, the OS I'm writing, all commands (administrative or otherwise) will appear to be in /bin, and all daemons will appear to be in /sbin (with corresponding symlinks in /usr). The separation into administrative and regular commands will be meaningless since the traditional root/non-root security model will be completely eliminated in favor of role-based access control. The / and /usr separation will be useless since it will be impossible to have a separate /usr partition (the contents of the root will be dynamically bound from a collection of individual package directories, and won't correspond to the root of the system volume).