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 7E58B138334 for ; Mon, 5 Aug 2019 23:34:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 25AA9E0848; Mon, 5 Aug 2019 23:34:25 +0000 (UTC) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 5F3C6E078A for ; Mon, 5 Aug 2019 23:34:24 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id x4so32837555wrt.6 for ; Mon, 05 Aug 2019 16:34:24 -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=T5XCFl9+gDT2IiEzcKfeENxu/uZmaNN9n5uP0sFnxGI=; b=k2zlL0ErCmn6oEuZ650ricvltwhZzc6QAU8oke1HJe/tOfY0FtW9kIUNAfM5gmt8QO t7pylcAu3T03+O756EK23MSOaXY5qG8kasrJj+LNrUmxbECocIpnI3IjLSwNasqUlDvJ 4OXipHjQ/uXKx/ayttaC9yLxyImIOSFS184Uw90JvOUbM3XllPzucnUa+LhDb9JJ5146 I0tyFC1R/1FeGYjZ5vzNCqvEPlyhcg3RjHvzoUSLoWYu1xBsYrjteCFQq3p1OUd/EYPZ Oi9sbnVp8/mJ3p5dA8K4wPBbPeEeiBDL1GK4uaKPB4OAnTa8FbZDqohZEhqn6aIsfYXS 5pTA== 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=T5XCFl9+gDT2IiEzcKfeENxu/uZmaNN9n5uP0sFnxGI=; b=J0drm5WKrHPY/0Iuf0b4Xg346n+mpQr9C4u08zgmMe+MGo/vwNBqN0QIyzb3Fg2EIv NlxmHdtvmGwQImLZqi1cbRr34+iCmVHXYGDcjs2i80a3VyktaZKa7UIq/vhUEF2q3AQy qrBH7Cd7Z53e0aFaUFIDoRoljBAxF48sZ5L6OMxqyG+VbFZspK1M+qpCA3pUqQ3ZUTXB Hg+BaZCrCvUejAiXPRiHULqQZcZi6eBaUNVlB5UypoDBWK+E6d0uhJsiL1+qQp/SG65C HJh9Mk3pwhRzea/zEBUTtZ7j4qQzSS5xDvaSLG8VECoS34zBAgBeH0rzOHcpCVeM8jZW pW1Q== X-Gm-Message-State: APjAAAWI6Hzy4QwoL5QpuaA+AZ9Tb3RqdGvwdurCPzhpgfZPoZeZ4hOk ANWy76pTWiQXN3YUKHFPJENFJvWk X-Google-Smtp-Source: APXvYqwUnDlWEhS2/wUegJ1x/Nh1ixswiEDMnxMhabmefApb5EgCEtBY1VzlXQ5FK0WU9BGern5BLA== X-Received: by 2002:a5d:4205:: with SMTP id n5mr371122wrq.52.1565048062602; Mon, 05 Aug 2019 16:34:22 -0700 (PDT) Received: from localhost.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by smtp.gmail.com with ESMTPSA id s2sm68325357wmj.33.2019.08.05.16.34.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Aug 2019 16:34:21 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: USE flag 'split-usr' is now global Date: Tue, 06 Aug 2019 00:34:04 +0100 Message-ID: <1589750.hRPUKH7mkQ@localhost> In-Reply-To: <86327492-b40a-fa37-83b3-c58b571b9685@spamtrap.tnetconsulting.net> References: <11147c49836aa1983da6a4a546fdf116@dyndn.es> <2332946.CxK0Tlp8m7@localhost> <86327492-b40a-fa37-83b3-c58b571b9685@spamtrap.tnetconsulting.net> 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="nextPart2754612.pWVCTSXJTQ"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Archives-Salt: f3e44b43-5fa0-4828-acff-41c9009d521d X-Archives-Hash: fc16af08ca1e4dcedcda73c60de68cdf --nextPart2754612.pWVCTSXJTQ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 5 August 2019 17:17:53 BST Grant Taylor wrote: > On 8/5/19 4:49 AM, Mick wrote: > Just because it's the same developers promoting both does not mean that > any logic / evidence they might provide in support of /usr merge is > inherently wrong. We should judge the merits of their logic / evidence > on it's own, independent of what we think of their other work. (Read: > Don't turn this technical conversation into a character discussion.) I am not entertaining ad hominem attacks on whoever may have been involved = in=20 such decisions. Only the impacts of such decisions on gentoo in particular. > > Sure, but for how much longer? >=20 > /me looks around for something that he must have missed. I probably used an incorrect figure of speech and caused confusion. We're= =20 only discussing the merge of /bin and /sbin to /usr/bin and /usr/sbin (it=20 seems to be more nuanced than this though - see gentoo forums thread furthe= r=20 down). However, the takeover of Linux in general by systemd architectural= =20 changes is a fact. It is also a fact gentoo has been changed a lot to=20 accommodate systemd. I have set USE=3D"-systemd" but still end up with ser= vice=20 unit files on my system, unless I take additional steps to remove/mask them= =2E =20 At some point udev/dbus/what-ever will be irrevocably linked to systemd, ju= st=20 because its devs do not care for alternative architectures. Some packages= =20 require systemd components, like (e)logind, and so on. Some years ago eude= v=20 was forked from systemd with a stated aim at the time to also restore the=20 borked separate /usr without an initrd - did this ever happen? There is a= =20 direction of travel and it has been influenced heavily by systemd design=20 decisions. > I didn't see anything about combining bin and sbin. There isn't any - I haven't seen it either. Sorry if I confused the point. > Let's focus on the /usr merger discussion /first/. Then we can address > bin vs sbin. >=20 > > 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. >=20 > Again, focus on technical, this is not a character discussion. >=20 > I also don't think they will be successful in foisting their ideas on > *all* users. I'm quite confident that there will always be some random > distro that does not subscribe to them. Maybe the usable percentage > will be quite small. But any distro that doesn't tow the line means > that not /all/ distros follow the agenda. (Yes, I'm saying distro > instead of user, but I think you understand either way.) >=20 > I personally don't like the idea of /{,s}bin being a sym-link to > /usr/\1. I like the idea that / (root) and /usr are (or can be) > separate file systems. That being said, I've not actually /needed/ them > to be separate file systems in quite a while. I may have /wanted/ them > to be separate so that I could utilize different file system types for / > (root) and /usr. Yes, same here, but this is primarily because since gentoo's change in this= =20 area I moved away from using a separate /usr fs to avoid having to use an=20 initrd. > Looking back at all the systems that I've administered for the last ~20 > years, almost all of them did use a single file system for / (root) and > /usr. Sure, they likely had other file systems as well; /var, /tmp, and > /home most likely. >=20 > Given how Unix / Linux is changing=E2=80=94evolving=E2=80=94where and how= it's being > used, I can see how there is no longer any need for the separate file > systems. I think this lack of need combined with the additional > complexity is evolving into a desire for a single file system for / > (root) and /usr. Since I can't point to any specific use case=E2=80=94in= about > 90 seconds=E2=80=94that a single file system would break, I'm pausing and= thinking. >=20 > So, since we're discussing it, I invite you, and anyone else, to list > pros and / or cons for either methodology. I'm quite interested in > learning what others think. I have given one benefit of keeping a separate fs for /usr, mounting it rea= d=20 only for daily use. Or you could have a shared NFS partition across variou= s=20 client PCs, facilitating system duplication. You could also have /usr on a= =20 faster disk for performance reasons. A benefit of /var being separate (or wherever www/, logs/, mail/ and databa= ses=20 are stored) is so that if it runs out of space the remaining system is not= =20 brought to its knees. Ditto for /home, with the addition of encrypting user's data/partition and= =20 mounting it with nosetuid (to prevent the users from running their own secr= et=20 root shell). So at least two reasons, helping to manage (simply) access rights and space= =20 are valid enough reasons IMHO to not remove a separate /usr option from=20 gentoo, but I'm interested to hear what others think. One might argue you= =20 still retain the option of using a separate /usr, but with the new added=20 restriction of being obliged to engage in boot time gymnastics with an init= rd,=20 LVM, your mount-bind solution and whatever else. However, workarounds whic= h=20 add complication (remove simplicity and flexibility) to fix something after= =20 breaking it, is what all this argument is about. Such changes remove choic= e. > I will warn you that I'll likely respond with counter points and / or > workarounds. I will also expect that you will respond in kind to my > response. >=20 > 10 point > 20 counterpoint > 30 counter counterpoint > 40 goto 10 I'll try not to mess up the thread. :-) > > I think following the lib directories merge, the discussion is now about > >=20 > > merging: > > /bin -> /usr/bin > > /sbin -> /usr/bin > > /usr/sbin -> /usr/bin >=20 > Let's fully qualify those directories. ;-) >=20 > I've not seen /any/ discussion about merging bin and sbin. Perhaps I've > just missed it. I'm going to ignore the merging of bin and sbin for the > time being. Please do, the systemd merge refers merging /bin to /usr/bin and /sbin to / usr/sbin. https://fedoraproject.org/wiki/Features/UsrMove However, this gentoo thread mentions further merging, which made my head sp= in: https://forums.gentoo.org/viewtopic-p-7902764.html > So the /bin vs /sbin split that you're referring to doesn't jive with > the history that I've seen / read / heard time and time again. You're probably correct. In any case, the initial move of subdirectories o= f=20 the / fs to different physical disks and hence different fs' was for storag= e=20 space reasons. > My understanding is that /sbin was originally intended for binaries > needed to bring the system up. (I view the "s" in "sbin" as meaning > "system (binaries)".) Yes. > Similarly, my understanding is that /bin was originally intended for > general use binaries that were used by more people. Yes, for plain users. > Note: The same understanding applies to the directories wherever they > are located, / (root), /usr, and /usr/local. Yes. > > 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. > That sounds good. But please put some details behind it. What do you > think the purpose of the directories was? (Please provide your > counterpart to what I outlined above.) >=20 > > The passage of time has introduced shared libs, which necessitate > > certain directories being on the same fs. >=20 > Nope. I can't agree to that. >=20 > Nothing about shared libraries necessitates that they and the binaries > that use them /need/ to be on the same file system. OK, I'll rephrase this. Certain binaries require corresponding libs to be= =20 accessible at the same time and /libs under /usr mushroomed to allow a=20 separate /usr partition to function. > Yes, they need to be administered in concert with each other. But they > can be in any directory (assuming proper configuration) on any > accessible file system. >=20 > We've had binaries in /usr or /usr/local or /opt or NFS mounts that rely > on libraries in /lib. They have been working across file system > boundaries for decades. >=20 > > Back then everything was statically linked so fs could be more > > independent. >=20 > Yes, shared libraries and their associated dynamic, non-static, binaries > have complicated things. But they don't necessitate that the binaries > and associated libraries be on the same file system. ;-) You are right, they just require to be accessible at the same time, which=20 during boot time when some fs are not yet mounted (e.g. /usr) could cause=20 breakage. > > 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. >=20 > How do you justify what was the /primary/ reason for the split as > secondarily important? It is secondarily important today, although at the time disk space was the= =20 primary reason for migrating fs away from / partition. > Or are you diverging from history and now going into what you would like > to see in the future? What I was trying to say is, today storage space is usually a smaller and=20 cheaper problem than it was at the early stages of UNIX and therefore *toda= y*=20 it is likely different purposes could be listed as having a higher priority= =20 for requiring different fs' to be deployed. Discovering my flexible gentoo= =20 system won't boot without an initrd, just because binary distros use initrd= by=20 default, should not be the logic for limiting architectural choices, on=20 gentoo. We should pause, discuss and (hopefully) agree. > > 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. >=20 > Be careful with that statement. >=20 > Here's how that played out in my head: >=20 > "If you (Developer) can't / won't follow the Gentoo way, then you need > to go elsewhere." The Gentoo Trustees should do just that, i.e. ensure the project follows th= e=20 Gentoo way. No.1 Gentoo Principle: "Gentoo provides choices." https://wiki.gentoo.org/wiki/Foundation:Main_Page If some dev, i.e. a gentoo community member who is contributing code, limit= s=20 choices for users, then it follows his/her code does not fit into Gentoo an= d=20 therefore Gentoo *should* not adopt it. If s/he is a project lead and push= es=20 changes against the Principles, then technical decisions on such matters ca= n=20 be taken by the Gentoo Council, but it is ultimately down to the Trustees t= o=20 straighten out deviations from the Gentoo Principles. I've written this as= if=20 it is black and white, but of course there are various shades of grey in- between. Either way, making one wrong decision at at time could end up wit= h=20 Gentoo gradually mutating into a systemd solution, which has already=20 restricted choice (udev -> usr -> initrd). > To me, that's antithetical to Unix's open methodology of "I made this, > if you can use it, great!". It also feels rather Debian ish to me. > "No, we don't accept your licensing for Mozilla Firefox, so we will fork > it and make our own program based on your code." I did not mean it this way. Code is gratefully received, but let's not cha= nge=20 Gentoo because any code was received. The shoe has to fit the foot. > > 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, >=20 > This is /far/ from a Linux thing. It may (now) be more prevolent and / > or visible in Linux. But this very thing has existed in Unix for the > last 40+ years. >=20 > > but I understand why it would not suit cookie-cutter thin provisioned > > VM images. >=20 > Please enlighten me why this might not suite cookie-cutter thin > provisioned (virtual) machines. Because RHL devs have particular use cases in mind. For them /usr on a=20 separate fs without an initrd is a "custom setup". > Note: Virtual or not makes effectively no difference. Agreed. > Unix and Linux distros have been automating the deployment of multiple > partitions ~> file systems for 30+ years. This is nothing new. We do > and have had the tools to do this for a long time. >=20 > The only thing that I see changing is people are asking /why/ there are > separate partitions ~> file systems. More specifically, they are asking > why they can't be one partition ~> file system. I think asking those > questions is a very good thing. Sure. Investigating opportunities to improve Linux is laudable. > Note: Asking the question indicates that someone is paying attention > and thinking. The act of asking the question and listening ~> thinking > does /not/ mean that things are going to change. Right, until udev won't work without /usr being mounted and then an initrd = is=20 a must. > Remember, thin provisioning is possible on physical systems connected to > SAN too. >=20 > > This brings my understanding to today's purpose of having different > > /bin, / sbin, /usr/bin and /usr/sbin directories as per FHS: > >=20 > > /bin should contain binaries that need to be available in single user > > mode for all users, like ls, cp, cat. > >=20 > > /sbin is for system binaries, like fsck, route, init, halt. > >=20 > > /usr/bin is for non-essential binaries for all users, your everyday > > desktop applications. > >=20 > > /usr/sbin is for non-essential system binaries like daemons, network > > utilities, some fs utilities. > >=20 > > The above FHS logic questions why you would need /usr to be mounted > > in order to boot the OS, >=20 > I don't think it questions anything. On the contrary, I think it calls > out that /usr should /not/ be needed to boot the system. Yes, until we started deviating from it, because someone offered us code. > I'm afraid that some people think of a community as their walled garden > and that everybody inside of it must do the same thing. Gentoo is by principle more accommodative than binary distributions and I'd= =20 rather it remained so. > I think of a community as people that have some overlapping ideas and > differing ideas that benefit from each other, including the different > perspective. I certainly hope that these types of communities don't > shun / exclude outsiders simply because they think or do something > differently. Agreed. I'm not advocating stifling discussion or innovation. > Aside: I'm watching Old Usenet (currently from '89) where people are > publishing what they have done that has worked for them. The spirit is > akin to "Here's something. If you can take it, adapt it, and use it, > then please do so." Right, which is rather different from: We've outsourced code development to RHL devs and we'll use whatever they f= eed=20 us, even if this changes our OS to a disagreeable degree. At the same time I know devs are a scarce resource and good devs even scarc= er,=20 so there will always be a need to avoid reinventing the wheel and use what= =20 upstream provide. I just hope the Gentoo principles hold a while longer. =2D-=20 Regards, Mick --nextPart2754612.pWVCTSXJTQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEt7MNaGaS6HvTUrEz6WnU8jC95dcFAl1IvOwACgkQ6WnU8jC9 5ddQ0A/9EiJbD/doSeLE9zZr2dGaFG7d9G3s1wT34/r66zf/3pTUY+zr6dvfdCac KFXMIhnwGJ/CMp2hndny4gK6KD+EDcTkAm/tCJG4HhlAIeakRdLkc/hWHkj9Cn13 ZhPFk3oHKeq40DqFZMmOuYi+J0HCM81FUVIyhBY4uex7PWKqt41VBmjwOTO9dRYE zn+4OsznKv9D0e0piQF7cTSVukzg6hvXZdGaC0oi18QI75qaTZaBn0OQIco2dzNx mZX3WK2202fUtGHbMehIXOGenTLN625F3TLW8/yQy4sG0/Ym3wCq2CfmYfJrqGmZ ugQdR9Rf2eG3Ku1W5n5Uf+mdXfya8JwlGAREUSjwil/kCNIDGDvoc+OGPdgWc6Qc Ki4UsjEvsJ7R67IjopTfRsjnRv1AXIUjWA7zdQ9FSwtPyxBK+DUIWspwiNx0WY6Z xgC0p2FeBR3wA6DgQndII5KW+k2hsyf3Uwm6LTtuHbyAPxEJjeY/+KRi/qUuKuHA TT+xvqxyffMOvW5oL8ug0bSWtlHDyhZ1UmWxisqn4WcdbOF7MepbL9DQ1Oh7q2uN EJNfyeD6Fjc5mX68jV8uzN9/9vzi8LAXl+FDDdbtBfu5tLbKSlj6hIKx4SVNhL3+ 3N3SHM+aRZVsmorGFbaYqueaNyW0pzK2nFp/GWqDF0s9beDnHhc= =h0zw -----END PGP SIGNATURE----- --nextPart2754612.pWVCTSXJTQ--