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