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 12E8F138334 for ; Tue, 6 Aug 2019 02:38:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0E8A5E088A; Tue, 6 Aug 2019 02:37:58 +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 7844FE0867 for ; Tue, 6 Aug 2019 02:37:57 +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 x762bsmn001480 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 5 Aug 2019 21:37:56 -0500 Subject: Re: [gentoo-user] Re: USE flag 'split-usr' is now global To: gentoo-user@lists.gentoo.org References: <11147c49836aa1983da6a4a546fdf116@dyndn.es> <2332946.CxK0Tlp8m7@localhost> <86327492-b40a-fa37-83b3-c58b571b9685@spamtrap.tnetconsulting.net> <1589750.hRPUKH7mkQ@localhost> From: Grant Taylor Organization: TNet Consulting Message-ID: <7264cb95-6c1f-560b-e04e-2b9303e1485e@spamtrap.tnetconsulting.net> Date: Mon, 5 Aug 2019 20:37:44 -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: <1589750.hRPUKH7mkQ@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Archives-Salt: 815d6713-6f36-4bbb-bdbd-d1af514362c0 X-Archives-Hash: 53339576522067aa31826d5fa34aebc9 On 8/5/19 5:34 PM, Mick wrote: > I am not entertaining ad hominem attacks on whoever may have been > involved in such decisions. Only the impacts of such decisions on > gentoo in particular. :-) > I probably used an incorrect figure of speech and caused confusion. > We're only discussing the merge of /bin and /sbin to /usr/bin and > /usr/sbin (it seems to be more nuanced than this though - see gentoo > forums thread further down). I started to read to be able to be informed when drafting my reply. Emphasis on "started". The first comment to the quote makes me think that it's going to be a lively discussion. I'll read it later as time permits and respond accordingly. > However, the takeover of Linux in general by systemd architectural > changes is a fact. It is also a fact gentoo has been changed a lot > to accommodate systemd. I have set USE="-systemd" but still end > up with service unit files on my system, unless I take additional > steps to remove/mask them. At some point udev/dbus/what-ever will be > irrevocably linked to systemd, just because its devs do not care for > alternative architectures. Some packages require systemd components, > like (e)logind, and so on. Some years ago eudev was forked from > systemd with a stated aim at the time to also restore the borked > separate /usr without an initrd - did this ever happen? There is > a direction of travel and it has been influenced heavily by systemd > design decisions. ACK I think I could draw analogies with XFree86 vs Xorg vs Wayland. In the beginning, nobody wants to actively stop development of the old method. But in the end, nobody wants to devote any effort to keep bring the old method forward. Thus the old method gets left behind. I'm not saying it's correct, or not, just that it is the nature of things. > There isn't any - I haven't seen it either. Sorry if I confused > the point. Actually, the quote in the first forum post you linked to has the following: /sbin->usr/bin /usr/sbin->bin That takes four directories (/bin, /sbin, /usr/bin, /usr/sbin) and combines them into two (/sbin & /usr/bin and /bin & /usr/sbin) but it also crosses bin & sbin as well as going opposite directions with the links. — Yuck!!! > Yes, same here, but this is primarily because since gentoo's change in > this area I moved away from using a separate /usr fs to avoid having > to use an initrd. ACK > I have given one benefit of keeping a separate fs for /usr, mounting > it read only for daily use. Or you could have a shared NFS partition > across various client PCs, facilitating system duplication. You could > also have /usr on a faster disk for performance reasons. ACK > A benefit of /var being separate (or wherever www/, logs/, mail/ > and databases are stored) is so that if it runs out of space the > remaining system is not brought to its knees. ACK > Ditto for /home, with the addition of encrypting user's data/partition > and mounting it with nosetuid (to prevent the users from running > their own secret root shell). ACK > So at least two reasons, helping to manage (simply) access rights and > space are valid enough reasons IMHO to not remove a separate /usr > option from gentoo, but I'm interested to hear what others think. Agreed.. > One might argue you still retain the option of using a separate /usr, > but with the new added restriction of being obliged to engage in > boot time gymnastics with an initrd, LVM, your mount-bind solution > and whatever else. I don't have any current first hand experience with /usr being a separate file system without using an initramfs / initrd. So I'm going to have to take what you, and others, say on faith that it can't /currently/ be done. But I've got to say, that I find that idea disturbing and highly suspicious. I'd be curious for pointers to bugs about this if you have them handy. Please don't look, I'll dig later if I'm sufficiently motivated. > However, workarounds which add complication (remove simplicity and > flexibility) to fix something after breaking it, is what all this > argument is about. Such changes remove choice. Ya. It's sort of like painting yourself into a corner because one (or more) too many bad decisions were made in the past. I'd much rather admit that a bad decision was made, undo it, and move forward again with new knowledge. Sadly, IMHO not enough people do that. > I'll try not to mess up the thread. :-) :-D I'll try as well. But I'm betting that we're both human. > 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 spin: > > https://forums.gentoo.org/viewtopic-p-7902764.html Ya. I need to read that thread in detail. The following bit concerns me. I do hope that it's a typo. /sbin->usr/bin /usr/sbin->bin > You're probably correct. In any case, the initial move of > subdirectories of the / fs to different physical disks and hence > different fs' was for storage space reasons. Agreed. > Yes, for plain users. I think it's for /all/ users, not just plain (non-root) users, because root will also want commands in /bin & /usr/bin for various things. I think of it more as non-root users don't /need/ the contents of /sbin & /usr/sbin for the vast majority of what they do. > OK, I'll rephrase this. Certain binaries require corresponding libs > to be accessible at the same time and /libs under /usr mushroomed to > allow a separate /usr partition to function. Agreed. > You are right, they just require to be accessible at the same time, > which during boot time when some fs are not yet mounted (e.g. /usr) > could cause breakage. Yep. I have historically considered what's on the / (root) file system to be what's required to boot-strap the system. Once the system has been booted, then all typical file systems are accessible. > It is secondarily important today, although at the time disk space > was the primary reason for migrating fs away from / partition. Okay. That makes more sense. Thank you for clarifying. > What I was trying to say is, today storage space is usually a smaller > and cheaper problem than it was at the early stages of UNIX and > therefore *today* it is likely different purposes could be listed as > having a higher priority for requiring different fs' to be deployed. Fair enough. > Discovering my flexible gentoo system won't boot without an initrd, > just because binary distros use initrd by default, should not be the > logic for limiting architectural choices, on gentoo. We should pause, > discuss and (hopefully) agree. Agreed. > The Gentoo Trustees should do just that, i.e. ensure the project > follows the 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, > limits choices for users, then it follows his/her code does not fit > into Gentoo and therefore Gentoo *should* not adopt it. I feel like there is an important distinction between what you have now said and what I meant with what you quoted. IMHO there is a big difference in the Gentoo community deciding (through due process) that the community does not want to include the developers code into the base portage. Conversely, I was originally meaning something along the lines of "you don't follow the Gentoo methodology, therefore you are forbidden from even applying to the community for inclusion." > If s/he is a project lead and pushes changes against the Principles, > then technical decisions on such matters can be taken by the Gentoo > Council, but it is ultimately down to the Trustees to straighten > out deviations from the Gentoo Principles. Oy vey! > I've written this as if it is black and white, but of course there > are various shades of grey in- between. *nod*nod* > Either way, making one wrong decision at at time could end up with > Gentoo gradually mutating into a systemd solution, which has already > restricted choice (udev -> usr -> initrd). I don't want to agree, but your logic is correct. > I did not mean it this way. Code is gratefully received, but let's > not change Gentoo because any code was received. The shoe has to > fit the foot. Agreed. Sometimes that means taking 95% of the code and modifying 5% of it to fit the Gentoo methodology. ;-) > Because RHL devs have particular use cases in mind. For them /usr > on a separate fs without an initrd is a "custom setup". Yet RHEL has Kickstart and many different ways to automate such "custom setups". Has RHEL gotten /that/ short sighted that they think there are no longer people that do anything but click next a bunch of times and accepting the default? *HEAVYsigh* Nevermind. Don't answer that. > Sure. Investigating opportunities to improve Linux is laudable. Very well said. > Right, until udev won't work without /usr being mounted and then an > initrd is a must. I need to do some research. > Yes, until we started deviating from it, because someone offered > us code. Is any distro following FHS even remotely faithfully any more? I thought most mainstream distros had moved on about ten years ago. > Gentoo is by principle more accommodative than binary distributions > and I'd rather it remained so. ACK > Agreed. I'm not advocating stifling discussion or innovation. :-) > Right, which is rather different from: > > We've outsourced code development to RHL devs and we'll use whatever > they feed 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 scarcer, so there will always be a need to avoid reinventing > the wheel and use what upstream provide. I just hope the Gentoo > principles hold a while longer. Maybe it's my Slackware roots showing. But I want to believe that it's possible to judiciously configure and compile software to work on just about any platform. (Assuming that the requisite version of libraries are somewhere on the system.) -- Grant. . . . unix || die