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 E0F74138334 for ; Mon, 5 Aug 2019 16:18:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 17C53E0817; Mon, 5 Aug 2019 16:18:08 +0000 (UTC) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26:8849]) (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 4DFDCE0805 for ; Mon, 5 Aug 2019 16:18:06 +0000 (UTC) Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id x75GI3vs015421 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 5 Aug 2019 11:18:05 -0500 Subject: Re: [gentoo-user] Re: USE flag 'split-usr' is now global To: gentoo-user@lists.gentoo.org References: <11147c49836aa1983da6a4a546fdf116@dyndn.es> <17607911.tSPHXFpkZT@localhost> <2332946.CxK0Tlp8m7@localhost> From: Grant Taylor Organization: TNet Consulting Message-ID: <86327492-b40a-fa37-83b3-c58b571b9685@spamtrap.tnetconsulting.net> Date: Mon, 5 Aug 2019 10:17:53 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 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 In-Reply-To: <2332946.CxK0Tlp8m7@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Archives-Salt: a93eb1fd-532b-4716-b65a-0da92ba07307 X-Archives-Hash: 66cf1464c676015f4271bdb75b178afc On 8/5/19 4:49 AM, Mick wrote: > It is being /assertively/ promoted persistently by the same devs. Okay. 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.) > Sure, but for how much longer? /me looks around for something that he must have missed. I didn't see anything about combining bin and sbin. Let's focus on the /usr merger discussion /first/. Then we can address bin vs sbin. > 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. Again, focus on technical, this is not a character discussion. 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.) 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. 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. Given how Unix / Linux is changing—evolving—where 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—in about 90 seconds—that a single file system would break, I'm pausing and thinking. 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 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. 10 point 20 counterpoint 30 counter counterpoint 40 goto 10 > I think following the lib directories merge, the discussion is now about > merging: > > /bin -> /usr/bin > /sbin -> /usr/bin > /usr/sbin -> /usr/bin Let's fully qualify those directories. ;-) 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. > 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. ACK > This initially led to /bin and /sbin split across different physical > devices and soon the same happened for /home, et al. That's different than the history that I've heard. Originally, everything was on one single disk. Then a second disk was added and /usr was created. User home directories were moved to /usr (hence it's name), and many of the same directory structures were replicated from / (root) to /usr. (Likewise with /usr/local on other Unixes / Linuxes later.) Then a third disk was added and /home was created. User home directories were moved to /home. 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. 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)".) Similarly, my understanding is that /bin was originally intended for general use binaries that were used by more people. Note: The same understanding applies to the directories wherever they are located, / (root), /usr, and /usr/local. But, I am ~> we are, ignoring bin vs sbin for much of this message and focusing on /usr merge. ;-) > 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.) > The passage of time has introduced shared libs, which necessitate > certain directories being on the same fs. Nope. I can't agree to that. Nothing about shared libraries necessitates that they and the binaries that use them /need/ to be on the same file system. 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. 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. > Back then everything was statically linked so fs could be more > independent. 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. ;-) > 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. How do you justify what was the /primary/ reason for the split as secondarily important? Or are you diverging from history and now going into what you would like to see in the future? > 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. Sure. > 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. Okay. > 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. Be careful with that statement. Here's how that played out in my head: "If you (Developer) can't / won't follow the Gentoo way, then you need to go elsewhere." 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." Please be careful. If that's what you /mean/ to imply, well.... If it's not, be mindful of how someone that you're telling to change might receive it. > 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, 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. > but I understand why it would not suit cookie-cutter thin provisioned > VM images. Please enlighten me why this might not suite cookie-cutter thin provisioned (virtual) machines. Note: Virtual or not makes effectively no difference. 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. 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. 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. Remember, thin provisioning is possible on physical systems connected to SAN too. > 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, 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. > 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 think that initramfs / initrd is a bit of a hack to make it simpler for distributions to boot without any knowledge of the hardware that they are booting on. I personally have never used an initramfs / initrd on any of my Gentoo systems. I have a kernel with the necessary drivers built in and I pass the root device as a command line option. Admittedly, almost all of my systems are not using anything like iSCSI or multi-path for the / (root) file system. Though I think it's particularly likely fair to say that the vast majority of systems qualify there too. VMs and containers are even more likely to qualify too. > 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. 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. 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. 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." > 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. I'm not convinced that /bin & /sbin /need/ to be separate from /usr/bin & /usr/sbin. Yes, they certainly can be. FHS speaks to why /it/ (as opposed to a different file system hierarchy standard) does what it does. Your /preference/ is exactly that, a /preference/. You are obviously free to have your own preferences. But a /preference/ does not directly translate to a /need/. ;-) > 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've not installed a Gentoo system onto a separate /usr file system in quite a while. So I can't speak with any current authority as to if it's possible or not with /Gentoo/. I do know for a fact that it is quite possible to install other /distributions/ onto separate file systems /without/ an initramfs / initrd. > 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. My opinion is that an initramfs / initrd is a hack used by distributions to make their lives easier. I remember the days when Slackware had a HUGE kernel that included an extremely large number of drivers /in/ /the/ /kernel/ so that it could boot and see the vast majority of hardware. Then you installed what you needed where you wanted it, all without an initramfs / initrd. One of the first things that was frequently done was rebuilding a kernel that only had the drivers that you needed. About the only thing that I'm aware of that /necessitates/ an initramfs / initrd is complicated storage like iSCSI and / or multi-path SAN attachments for the / (root) file system. Maybe for 3rd party binary only drivers for local storage. Beyond that, I'm not aware of anything that can't be done from the / (root) file system. I guess disk encryption would also be another thing. Though I've not /seen/ the / (root) file system encrypted on servers. I have read about some people doing it on VPSs. (My VPS has an unencrypted root with a LUKS encrypted data partition.) > 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. You are free to have any preference you want. As are we all. Sometimes we have to decide if we want to allow our preference to make decisions for us by excluding options that don't honor our preference. > 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 Sadly, that doesn't give any context, much less history. I assume that's contained in a mailing list archive somewhere. > 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 Fair enough. That mirrors my logic process on many things too. Aside: I questioned the need to remove Token Ring support from 3. kernels. I question the need to remove floppy drive support now. > the community at large agrees with it after being presented with the > factual arguments for and against. Sure. > 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 Agreed. > and the only reason to change is so that gentoo becomes aligned with > the systemd project. I don't think alignment with another project is a valid reason. I am willing to entertain discussions about the ideas why other projects have done something and assess if we want to make a similar change independent of the project that we are observing make the same change. Read: · I /don't/ want to start cooking my food because my neighbor is doing it. · I /do/ want to start cooking my food because I think that cooked food is tastier than uncooked food. > Let's review any changes on their merits *before* they are implemented. Sure. -- Grant. . . . unix || die