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 6908 invoked from network); 24 Feb 2021 03:13:00 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 24 Feb 2021 03:13:00 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 07DFC9C7DD; Wed, 24 Feb 2021 13:12:59 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id D73699C6D0; Wed, 24 Feb 2021 13:12:28 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="SjwCrL16"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 6E4C19C6D0; Wed, 24 Feb 2021 13:12:26 +1000 (AEST) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by minnie.tuhs.org (Postfix) with ESMTPS id AF1969C6CE for ; Wed, 24 Feb 2021 13:12:25 +1000 (AEST) Received: by mail-io1-f49.google.com with SMTP id n14so544814iog.3 for ; Tue, 23 Feb 2021 19:12:25 -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=C3Oqh/R276wnZ4eHXhvQrXbx1WDYzU0ko4Tijp+49bM=; b=SjwCrL16mN69/A/7HVm6aYcSyoD+59dWFC6PEC/AHi/8lXingQbQF9frDbAH7pskuB YQxHiPyRI3hW2AkqA/ykx23kTzljbPLwV9h8XiGMFNX7/zvT3PUjS+FvzI6rr9nP45Vx 0z050OeG+6mEKmR1McVX7rVvRPN3ZyxrrIJZDa9xDzolfk1BsDbqSI+1uQ42y3T0sfW+ 2Q0B9zv1xnNS+J6j7C756q8Vi4KynRjvKk24nhNM3Gv3dGiSFWuV8GUhuya2z8XjsAnP wxGVyi0dnE8UT88FBA/O2RoxNDFs7VhtUpWG2o98+9exvqpd9Rc9aRdB/59WSpLgsawE H4CQ== 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=C3Oqh/R276wnZ4eHXhvQrXbx1WDYzU0ko4Tijp+49bM=; b=UMfiF9pUqMzHpgA7habvCAwbbOxm36uJ8TO7IHYhvzEGTYsONyEV2voyDzcbGgvAXI KsowPeeQKXIRKj1OvpR3apz2pTnzbL+pHtD6nxb4xVnC2s7OXbKX+2xdu8HXSNziiHNU d9PFzXThtoQsgR5DCEPzng8+qc39GfhawgTdg50F48Fm/v5NVHGnqAZ1YKg6cG2VCnTK 3YCtmDuAQt88uXqfut1xkNXp+T1sfBfuey7Zj1wD5/VFLuKXr4+kbzGn4I6pXFzROern J8ALHyFvYqDuZEg2/X7Yk325k0xgTIaGEB+lqQ0zGKhnRxyDT+gLPjKSNuuBDkdHn4bZ qBIw== X-Gm-Message-State: AOAM533eHGvedzDzaPZ2+8oZFqWhCdISPZtToGzYEnKKgng/FQ79e70X Ta13nRdwPdAJIFy/WKCukltN+yVJ8hZdSM5tWIDB5V2d X-Google-Smtp-Source: ABdhPJzmdwnuWi/6EKnPaJ1f0cn9GAQuKZ/ugpRFQq+2qtgnMSPCm+LLD+MsdzLu9f0Z5K2Q83u343ap0sJcNxMUXEM= X-Received: by 2002:a05:6638:3389:: with SMTP id h9mr13603897jav.65.1614136344490; Tue, 23 Feb 2021 19:12:24 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ac0:eda8:0:0:0:0:0 with HTTP; Tue, 23 Feb 2021 19:12:23 -0800 (PST) In-Reply-To: References: From: Andrew Warkentin Date: Tue, 23 Feb 2021 20:12:23 -0700 Message-ID: To: The Unix Heritage Society mailing list Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] /usr separation (was: 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/23/21, Greg A. Woods wrote: > > For one there's a huge amount of deeply embedded lore, human (finger and > brain) memory, actual code, documentation, and widespread practices that > use this separation and rely on it, effectively making it a requirement. > That is only a justification for keeping the /usr hierarchy around (and using symlinks/binding to make stuff appear in both places), not for arbitrarily separating programs and libraries between the two. > > However the reality of maintaining a separate minimal toolset for system > bring-up is that it cannot be reliably done without constant and > pervasive testing; and the very best (and perhaps only) way to achieve > this, especially in any smaller open-source project, is for everyone to > use it that way as much of the time as possible. I say this from > decades long experience of slowly moving systems to having just one > partition for both root and /usr and then on occasion testing with > separate root and /usr, and every time I do this testing I find > dependencies have crept in on something in /usr for basic booting. (and > that's even when I base my system on a platform that still tries hard to > maintain this separation of root and /usr!) > With a system-wide package manger a set of basic packages can be maintained without having an arbitrary separation into root and usr. The reference distribution of UX/RT will have several nested sets of packages rather than a separation of binaries between root and usr. The smallest will be what is included in the supervisor image (the equivalent of a kernel image and initramfs combined into one), which will be what is required to mount the system volume. Above that will be the minimal system, which will be the set of packages required to boot to a multi-user login. All of this will be in the base system repository, along with a few other optional groups of packages (including a full desktop environment). Most optional third-party application packages will be in a separate repository (like ports or pkgsrc under BSD, but using the same package manager as the base system and available by default without any special configuration). On 2/23/21, Theodore Ts'o wrote: > > /boot needs to exist due to limitations to the firmware and/or boot > loader being used. If the boot loader is using the legacy PC Bios > interfaces to read the kernel and initial ramdisk/file system, then > those files need to be in a low-numbered LBA disk space, due to legacy > BIOS/firmware limitations. It could also be a concern if you are > using some exotic file system (say, ZFS), and the bootloader doesn't > support that file system due to copyright licensing incompatibilities, > or the boot loader just not supporting that bleeding-edge file system. > In that case, you might have to keep /boot as an ext4 file system. > The BIOS addressing limitations only happen with CHS-only BIOSes, which haven't really been a thing since the mid-to-late 90s. The only reason to have a separate /boot partition for anything newer than that is because of bootloader limitations. On 2/23/21, Grant Taylor via TUHS wrote: > > I have a different conundrum regarding */bin. Why do I need nine > different (s)bin directories in my path? I -- possibly naively -- > believe that we have the technology to have all commands in /one/ > directory, namely /bin. > > Quickly after that thought, I realize that I want different things in my > path than other people do. So I end up with custom /bin directories. > Which usually ends up with sym-links that reference variables or custom > mounts (possibly via auto-mount applying some logic). > UX/RT will solve the issue of different sets of programs in the path in different user or application contexts with per-process and per-user namespaces (since fine-grained security will be deeply integrated into the system and neither on-disk device files nor setuid binaries will exist, there shouldn't be any security concerns with letting regular users bind and mount stuff for themselves). $PATH will just be set to "/bin" in the vast majority of cases.