From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 46ABA138334 for ; Mon, 5 Aug 2019 10:49:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AFD79E08AC; Mon, 5 Aug 2019 10:49:51 +0000 (UTC) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2577CE0899 for ; Mon, 5 Aug 2019 10:49:50 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id x15so74274429wmj.3 for ; Mon, 05 Aug 2019 03:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=qyIHG99/2qh8Cl0wyBzQ3dxq9BHDq2GaGyQl+KW4z00=; b=FkELWACWFF9U4LQ14D/WPP+CK9wsR/i2TYHMxtOKpbOCYfnKOVehyepnlDkZHxaPZi 9+coVUswqzviF+Yn9xbFkX/LREdlTi9VcFJl5NGt39zcNZojYqjrUHpGzs8UlXm5ytyl pfC6QtHdmdwD2f5ZPdE4X0SHTikYKAylbZH9LeJ3va2X0djg3xaDBVGLl+gQXmqV+51t /vXacrz6ogjrpHTaB1iSRDccWZj9jzPUgJwYYktlsUNuBFQAGKlPLPqEVOV977NtIjOk +sfkHnBjmKp3efXIiLkJP2lrdCUoPuekv6Z8hoVdcNTXGL59Q8040WLtY/JIUO5gaGFe GK4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=qyIHG99/2qh8Cl0wyBzQ3dxq9BHDq2GaGyQl+KW4z00=; b=TgCptqHjcLqP9pk8eIzzPtJp6oOB52tq8aI7/DHNAgL8qYRMJwetK70uil2VFIWAxl NUpvI2vz14+3y+cf1jp8LfpekwKbZUbdeJF+gwCPvSGmsCHdq2ZCDKwM2l3CRONhr0LV q1jGMJ5gJddJqdgiLxaoo8C3+DzqKAr3diMmfIVDYtkH/Ma7HhAK/hkmILiXZ9NHc8dL vk7rWHifX20k6oAuF96WI7Lby2Ec9oBClaagg60VMRB+fJBbQFwcA8juzcW3jGk+SLa/ kATL/G681P6Yd0AYXN8clLzbSc7DojCR3O8Ai4iM7rnWDqBVxEdSogxeX/lnq6U1i5go rWDQ== X-Gm-Message-State: APjAAAVwOQWux6zOcQjFlgD/99zGoCY0kyQGHNMZWHFUXzBwV80W2nr+ 9UvpJue7IBZyZUopKfarSY+wiD9Q X-Google-Smtp-Source: APXvYqxm/XH7euqHyks/gDr5KxuV4irCOx04y38f1zoqYQ4IIiOU2Zo3gkxs+FRTBf0UIjmhYBu3oQ== X-Received: by 2002:a1c:35c2:: with SMTP id c185mr17947917wma.58.1565002189409; Mon, 05 Aug 2019 03:49:49 -0700 (PDT) Received: from localhost.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by smtp.gmail.com with ESMTPSA id c7sm76724689wro.70.2019.08.05.03.49.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Aug 2019 03:49:48 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: USE flag 'split-usr' is now global Date: Mon, 05 Aug 2019 11:49:39 +0100 Message-ID: <2332946.CxK0Tlp8m7@localhost> In-Reply-To: References: <11147c49836aa1983da6a4a546fdf116@dyndn.es> <17607911.tSPHXFpkZT@localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2951347.MItgBlCH6v"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Archives-Salt: 074fcf33-2e61-4be2-88c9-bfab164767e4 X-Archives-Hash: ca2a8a01e0675bda97f0d5f4cc53a23d --nextPart2951347.MItgBlCH6v Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" On Monday, 5 August 2019 02:26:11 BST Grant Taylor wrote: > On 8/4/19 12:03 PM, Mick wrote: > > I don't know more about this, but it seems we are being dragged towards > > a systemd inspired future, whether the majority of the gentoo community > > of users want it or not. > > How is the /usr merger /directly/ related to systemd? It is being /assertively/ promoted persistently by the same devs. > > In my view system binaries should not be thrown in the same pot as user > > binaries and keeping the two separate makes good sense for those of us > > who do not spin up 200 cloned VMs a second on a RHL corporate farm. > > What are you using to differentiate system binaries and user binaries? > Are you using the /usr directory? Or the bin vs sbin directories? > > Please elaborate on your working understanding. I ask because I want > correctly understand you and speak to what you're talking about. > Especially considering that there will still be the bin vs sbin directories. Sure, but for how much longer? You need to check the direction of travel here and how long before a particular dev priesthood which imposes initrd, systemd and a single partition image, or whatever suits their mass market use cases agenda, foists their choice upon *all* users. I think following the lib directories merge, the discussion is now about merging: /bin -> usr/bin /sbin -> usr/bin /usr/sbin -> bin Since you asked this is my understanding, which may need correction by more learned contributors, because some of this has happened well before I sat in front of a keyboard. Back in late 60s, early 70s, disks became larger as UNIX was getting bigger. This initially led to /bin and /sbin split across different physical devices and soon the same happened for /home, et al. This historical fact of UNIX evolution to use multiple and subsequently larger storage devices is being conflated with the purpose of these directories, what they were created for back then and what their use should be today. The passage of time has introduced shared libs, which necessitate certain directories being on the same fs. Back then everything was statically linked so fs could be more independent. Whether the *initial* directory split across different fs was introduced because UNIX had put on weight and disks became larger is of secondary importance IMHO. As a user I tend to focus on the current usefulness of different *choices* and understand it is preferable to retain them architecturally as choices to also suit other users' preferences and use cases. I'm talking about an acceptance of Linux and Gentoo in particular as a meta-distribution being created for the benefit of a community of users which is wider than my single interests and needs, but also wider than individual developers agendas and preferences. That said devs are of course free to develop what they like, want and prefer, but if they cannot/will not serve the wider needs of the project and its community, then it may suit them to look for a new project. As the world moved on and Linux was created, the split fs concept grew legs and different distros made their own choices how different directories/fs were created and their permanence between reboots, e.g. /tmp, /var/tmp, /usr/tmp etc. This created the known Linux fs architecture variability which could well suited the particular distro communities who introduced it, but I understand why it would not suit cookie-cutter thin provisioned VM images. This brings my understanding to today's purpose of having different /bin, / sbin, /usr/bin and /usr/sbin directories as per FHS: /bin should contain binaries that need to be available in single user mode for all users, like ls, cp, cat. /sbin is for system binaries, like fsck, route, init, halt. /usr/bin is for non-essential binaries for all users, your everyday desktop applications. /usr/sbin is for non-essential system binaries like daemons, network utilities, some fs utilities. The above FHS logic questions why you would need /usr to be mounted in order to boot the OS, or why using an initrd to achieve it is what we should be doing in gentoo a meta-distribution, just because all binary distros do so. > > I'm not arguing against systemd, or merging all directories under an > > equivalent of a $WINDOWS/ path, but it seems to me a gentoo system > > architecture should retain the freedom of choice and flexibility it > > has been famous for. > > I agree that the user choice is *EXTREMELY* *IMPORTANT*! Yes, this is what *community* projects are constitutionally put together for. Otherwise we all have our own pet projects, but (I hope) we don't try to foist them on our friends and neighbors. > > Retrograde steps like being forced to use an initramfs just for > > retaining a separate /usr partition, should not be the way gentoo > > evolves. > > Agreed. > > I am curious why /you/ want (the ability to have) a separate /usr file > system. I know that I want to retain the ability. That being said, > I've not needed it in quite a while. For the good reasons presented above as per FHS I want to retain the ability of a separate /usr and I would much prefer it as it was before on its own partition and without an initrd. The /usr fs can be mounted as read only for an additional layer of security. I used to have /usr on a separate partition, but since initrd became a necessity to keep /usr separate I moved it under /. I have used initrds over the years and some of my binary systems have it by design, but it is not a design choice I want to adopt. I would still prefer / usr being on its own partition and without an initrd whether I use it today or not. I mean, if I want to use initrd, systemd, binary log files and whatever else, there are a tonne of binary distros out there to choose from. The *main* reason I use Gentoo is because of the user choice and flexibility it offers, something binary distros cannot provide. > I am also using a bit of a hack that I think could be (re)used to allow > /usr being a separate file system without /requiring/ an initramfs / > initrd. (I'll reply in another email with details to avoid polluting > this thread.) > > > Setting up a USE flag to accommodate such changes would be more > > agreeable for many gentoo users, rather than changing the default > > set up. > > Please forgive my ignorance. What was the default before 'split-user' > was made global? I assume that 'split-user' wasn't a default. So, by > my limited understanding, 1) it was / still is a USE flag and 2) has > chosen the more historically compatible as the new default. I don't know when it kicked in, because I don't follow the dev mailing list, but I assume it became necessary when the drive to align with RHL design principles started being implemented? https://packages.gentoo.org/useflags/split-usr > > NOTE: Please do not start a flamewar, I'm just expressing my opinion > > as a long term gentoo user who prefers to use gentoo for personal > > computing, instead of other binary systemd based distros. > > I'm not taking this as a flame. I'm taking it as an honest and open > discussion to learn what others are doing / thinking. > > For the record, I'm largely okay with /bin being a sym-link to /usr/bin. > However I do want /sbin to remain local to the root file system. I've > supported multiple installs where /usr was a separate file system and > needed the minimal system (not an initramfs nor an initrd) to fix things > at times. I'm also quite happy without an initramfs / initrd. I'd rather keep things as they have been/were until and unless the usefulness of a change weighs heavier than keeping them the same and the community at large agrees with it after being presented with the factual arguments for and against. By all means let's merge /bin into /usr/bin, but not if the caveat is we now *must* have an initrd to be able to boot and the only reason to change is so that gentoo becomes aligned with the systemd project. Let's review any changes on their merits *before* they are implemented. -- Regards, Mick --nextPart2951347.MItgBlCH6v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEt7MNaGaS6HvTUrEz6WnU8jC95dcFAl1ICcMACgkQ6WnU8jC9 5dcoNA//QDfhAXKxFpllFZ4j3Nbz/bCGolG+7ssVxCJjquVPc3BI2YszR3hYPWYp cY7tnuklF3PttfAX4bU8rEwdP3AcD7EoBJxnVlDgMQPvHvJb5oDuX+9Qc73wU3z/ KnzzGzB1DwTvKCWQ2ri0/uD4DzuwtbpNfzZ+p0qG6+VABcth/xSlLgrbuMNfnGL6 QfIBuoDyTBL2/GF0ey76WMUeYWAdXKHRl6S946iteslCZ670mG7sJIeEjvajGitY wGNsly3uFkcvkiU4AK3QM2UeLySwsll5dmrwySsnxso0IMM6oLaMn+ExlcfiH+2t tPicq6wOMv04qmsSU5i6onuaiwGVOcsnZNEocVfFFZkKLIDyOivHSCdGASBbYW2d 0RY4C4DkrFsEm5Qsr/I8v+bNa3JYEdkEfvPi4w5FynD55WdSYf74XzI2R0efpW/g x9wprxh/P24xwkBNMZOPd1PtPeRmlG8qeMycYp3pzBDWbWnu055nfAFwmL7b8OtH loF0AT3rjSlDXfoscryxClbrzvboNJyJ2VwXwTZ9u2QsIg09yf5zCi5PCX2wb95W gZ4a4VKIpsK3gA0S/ezH2MpAz1P1pN8MW/OZDeugIpv9C/r/lWK7n2sLxEznhYKZ 5ai8bAU4WYz2T4qCx/Sc7ES/erQW0qa/3yDi6YyI0SdPCQc2ZJU= =Kw0R -----END PGP SIGNATURE----- --nextPart2951347.MItgBlCH6v--