Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On 2019-08-08 09:43, Neil Bothwick wrote: On Wed, 07 Aug 2019 14:24:22 +0100, Mick wrote: > As opposed to splitting binaries across four directories based on > arbitrary decisions made in the last century? :P LOL! You're missing the most important part: across different fs and partition layouts. Look, the pyramids were built before the last century, but that doesn't mean we should try to balance them upside down if they work fine as they are. Why not? As long as it's optional and controlled by a USE flag :) Clearly different use cases have different requirements and correspondingly different optimal solutions. Can I please keep my bin/sbin directories separate and ditto for /usr and its subbies? :-) The /usr / split makes sense when you want different filesystems, something I used to do but don't have any need for now. I've yet to see a convincing argument for the bin/sbin split in either location. Let me jump back into this hi-jacked thread somewhere. Unfortunately I didn't found an answer to the future directions at gentoo regarding the usr merge. And my fear is that the merge will be forced. As I use gentoo as a meta distro really, this change _could_ be put _me_ into trouble. But my 'gentoo-lfs' is not the typical use case. Now, even that there are my individual requirements behind, some short points of my POV to some points in the whole thread. All IMHO. An initramfs is a elegant and - more important - a very flexible solution. It is not required, but it makes things easier. It could solve more things than having /usr at a separate fs or loading drivers. I would also define it as a bootloader (like Rich) in a chain. More abstract I would see a classical bootloader like grub as a kernel by itself. I see 3 stages of security concerns of an initramfs: 1. trust yourself and build your own one 2. trust gentoo and use gentoo's initramfs 3. download one (from a warez site) and stay hacked The usr merge itself is questionable workaround to consolidate things. Now, a consolidation is a good thing in general. But what is the real difference to have a symlink /bin against having a folder? I couldn't follow the given arguments. The core issue is the under laying folder structure. And depending on this hard coded path's. We still relying at a 50 years old concept - and time was moving on. Don't ask, I haven't a solution (yet). Just the dream/vision of the perfect system :). One point of the vision is to have a core (linux) OS (e.g. an extended stage3) separated from all user programs (similar to a ring0 kernel isolation). From all exiting concepts and implementations the best parts should be used. Not sure if this is ever possible. But forcing users to use a solution which is not required by 99% of them is a very bad thing. These '1-percent-solutions' have to be optional. Anyway, just an opinion beside the mainstream. I encourage people to have their own. :) It is not hard to create pro and con arguments. And I left enough room for misunderstandings. -- Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Wed, 07 Aug 2019 14:24:22 +0100, Mick wrote: > > As opposed to splitting binaries across four directories based on > > arbitrary decisions made in the last century? :P > > LOL! You're missing the most important part: across different fs and > partition layouts. > > Look, the pyramids were built before the last century, but that doesn't > mean we should try to balance them upside down if they work fine as > they are. Why not? As long as it's optional and controlled by a USE flag :) >Clearly different use cases have different requirements and > correspondingly different optimal solutions. Can I please keep my > bin/sbin directories separate and ditto for /usr and its subbies? :-) The /usr / split makes sense when you want different filesystems, something I used to do but don't have any need for now. I've yet to see a convincing argument for the bin/sbin split in either location. -- Neil Bothwick I doubt therefore I might be. pgp8J7r1LjBit.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On 8/6/19 6:31 PM, Rich Freeman wrote: So, an initramfs doesn't actually have to do ANY of those things, though typically it does. I agree that most systems don't /need/ an initramfs / initrd to do that for them. IMHO /most/ systems should be able to do that for themselves. Nothing prevents an initramfs from booting an alternate kernel actually, though if it does it will need its own root filesystem initialized one way or another (which could be an initramfs). Agreed. Though I think that's rare enough that I chose to ignore it for the last email. Linux bootstrapping linux is basically the whole premise behind coreboot. Sure. But coreboot is not a boot loader or a typical OS. coreboot falls into the "firmware" family. Sure, but you don't need it ALL OVER YOUR FILESYSTEM. I'd be willing to bet that 75% of what's contained in an initramfs / initrd is already on the root file system. Especially if the initramfs / initrd is tweaked to the local system. Taking a quick look at the default initrd of an Ubuntu 16.04 LTS, just about everything I see in the following output exists on the system. /boot/initrd.img-4.4.0-87-generic has 1908 items in it. 129 of them aren't already on the installed system. Consisting of: 51 /scripts Probably initrd specific 61 /bin May be in /sbin /usr/bin /usr/sbin on the local system. 6 /conf Probably initrd specific 5 /etc 2 /lib 4 misc Digging further, 29 of the 61 for /bin are in /usr/bin. 12 are in /sbin. That's 88 out of 1908 files in the /boot/initrd.img-4.4.0-87-generic file that aren't already all over your file system. Some of the proposed solutions in this thread involved sticking stuff in /bin and so on. An initramfs is nicely bundled up in a single file. So, you're saving 88 files (out of 1908) and storing 1820 additional copies of files that exist in a container that's not easy to work with. Why‽ Absolutely true, which means it won't interfere with the main system, as opposed to sticking it in /bin or somewhere where it might. How do the files that are needed for the system to operate, being placed where they need to be, interfere with the main system? Such as? Allow me to rephrase / clarify slightly. There have been many things that I've wanted to do in the past 20 yeras that the initramfs / initrd from the vendor did not support or was not flexible enough to do. · Not support root in LVM. · Not support root on LUKS. · Not support iSCSI disks. · Not support root on multi-path. · Not supporting the file system (tools). · Not support the RAID that (tools). · Not support ZFS. · Not support root on NFS. These are just the some of the things that I've wanted to do over the years that the initramfs / initrd as provided by the distro did not support. I have routinely found initramfs / initrd limiting. It is a linux userspace. It can literally do anything. Yes, /conceptually/ it's Linux (userspace) can do anything that Linux can do. /Practically/ it can only do the things that the distro envisioned support for and included in their initramfs / initrd management system. You don't need to use dracut (et al) to have an initramfs. (See above.) In fact, you could create your super root filesystem that does all the fancy stuff you claim you can't do with an initramfs, Sure. I did. (Time and time again) it was the machine's root file system doing exactly what I wanted it to do. then create a cpio archive of that root filesystem, and now you have an initramfs which does the job. Why would I want to copy / permute something that's already working to add as an additional layer, which I don't need, complicating the overall process‽ Sure, but only if the kernel can find that disk without any userspace code. There's a reason I said "if". The extremely large majority of the systems that I've administered over the last 20 years could do that. What if that disk is on the other side of an ssh tunnel? That would be a case where you would actually /need/ an initramfs / initrd. I'd like to hear tell of someone actually using a root disk that is accessed through an ssh tunnel. Short of that, I'm going to consider it a hypothetical. If you know the commands to do something, why would you have to wait for somebody else to implement them? Because I have hundreds of machines that need to be supported by junior admins and sticking within the confines of what the distro vendor supports is a good idea. Or more simply, sticking within distro vendor's support period. Actually, for most of these the initramfs is the starting root filesystem (just about all linux server installs use one). Remember, an initramfs / initrd is (or gets extracted to) a directory structure. Just about all of the servers and workstations (mid five digits worth) that I've administered over the years end up with a SCSI (SATA / SAS) disk off of a controller with the driver in
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Wednesday, 7 August 2019 12:48:08 BST Neil Bothwick wrote: > On Wed, 07 Aug 2019 11:58:52 +0100, Mick wrote: > > > Actually, it combines them all into one. The second link is to bin, > > > not /bin. It's a relative link from /usr/sbin so this would put > > > everything in /usr/bin. > > > > Yep! It sounds like an amazing idea! I vote we rename it $WINDOWS/ > > As opposed to splitting binaries across four directories based on > arbitrary decisions made in the last century? :P LOL! You're missing the most important part: across different fs and partition layouts. Look, the pyramids were built before the last century, but that doesn't mean we should try to balance them upside down if they work fine as they are. Clearly different use cases have different requirements and correspondingly different optimal solutions. Can I please keep my bin/sbin directories separate and ditto for /usr and its subbies? :-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Wed, 07 Aug 2019 11:58:52 +0100, Mick wrote: > > Actually, it combines them all into one. The second link is to bin, > > not /bin. It's a relative link from /usr/sbin so this would put > > everything in /usr/bin. > > Yep! It sounds like an amazing idea! I vote we rename it $WINDOWS/ As opposed to splitting binaries across four directories based on arbitrary decisions made in the last century? :P -- Neil Bothwick DOS never says "EXCELLENT command or filename"... pgpyjmOi9g8f7.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Wednesday, 7 August 2019 11:48:09 BST Neil Bothwick wrote: > On Mon, 5 Aug 2019 20:37:44 -0600, Grant Taylor wrote: > > 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!!! > > Actually, it combines them all into one. The second link is to bin, not > /bin. It's a relative link from /usr/sbin so this would put everything in > /usr/bin. Yep! It sounds like an amazing idea! I vote we rename it $WINDOWS/ and see how fast someone can spin an image on Azure. :p -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Mon, 5 Aug 2019 20:37:44 -0600, Grant Taylor wrote: > 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!!! Actually, it combines them all into one. The second link is to bin, not /bin. It's a relative link from /usr/sbin so this would put everything in /usr/bin. -- -- Neil Bothwick Exercise daily. Eat wisely. Die anyway. pgplegyUbUoHb.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Wednesday, 7 August 2019 01:31:03 BST Rich Freeman wrote: > On Tue, Aug 6, 2019 at 7:41 PM Grant Taylor > > Sadly, I think people have thrust additional (IMHO) largely unnecessary > > complexity into the init process just to be able to support more exotic > > installations. I may be wrong but I thought the udev-usr-initrd complexity was deemed a necessity/ when bluetooth input and audio devices became more widespread. The fact systemd gradually mushroomed to take over the OS is another more loosely related story. > > Then, they have said "We want to be consistent in how we > > boot, so we need to use this more complex thing everywhere." To which, > > many greybeards have responded "I don't need nor want that on my simple > > server." This is the main rub of these architectural /solutions/ being pushed onto the wider community by what amounted to corporate lobbyists, for /problems/ many of us never had. > Initramfs is popular because it is way more flexible: > > 1. You can build a fully modular kernel so that you can use the same > kernel on every system but not be loading countless drivers for > hardware most systems don't use, while still being certain of being > able to boot any particular system. Unless you have no use for this. Just as many *Gentoo* users do not need their kernel image blessed by Microsoft, RHL shims and what not. > 2. You have more access to labels/uuids/etc for finding the root > filesystem so that when one of your hard drive fails the kernel > doesn't just dumbly use the next one in sequence, assuming they're > even always identified in the same order. I may be missing something here ... but I think this is not related to the use of an initrd. You probably won't even need a separate bloat-loader like grub2 for this, at least not on UEFI systems. Just add the root PARTUUID on your kernel line, inside the kernel. > 3. You can use "exotic" installations like iscsi and so on, which > seems pretty useful in an enterprise setting. > > > If you /actually/ /need/ a micro installation to make your main > > installation available, then go for it. But if you don't /actually/ > > /need/ a micro installation, well Occam's Razor / Parsimony. I have not performed sociological research to confirm this, but I'd say to those of us identifying with the above statement Gentoo is a good fit. For those in an enterprise setting, there are many other cookie-cutter corporate solutions applicable. > Except then you're tailoring your bootloader to individual systems. Yes, I don't *have* to use Gentoo on a large server farm, put a SLA in place linked to contractual payment thresholds, hack my own monitoring system and get 3 layers of insurance signed off. Tailoring my bootloader(s) is something I do in my home-office environment, including 3 servers. > Most sysadmins will prefer the Ubuntu/RHEL/etc approach where the same > kernel/bootloader/etc works everywhere, vs tailoring their boot > process to every individual host. Yes in (large) corporate deployments. Some of them on Azure too. > > > They're a really elegant solution to the problem. > > > > I wouldn't use the words "elegant" or "solution". "kludge" comes to mind. > > What could be more elegant? It minimizes the complexity of the > kernel, which is why Linus generally prohibits the kernel from having > any more advanced root mounting logic, and why pretty much every Linux > system out there uses one. I think the whole issue is a difference in use cases and where corporate money has been used to provide a narrowly focused solution to address corporate requirements, without particular attention/interest/care to what are statistically edge use cases. Such edge use cases, e.g. separate /usr, no initrd or kernel images signed by Microsoft, different choice of bootloaders, etc. have been more concentrated on Gentoo than the one-size-fits-all binary distros. RHL calls these "bespoke" deployments. Yet when changes in udev brought about the necessity of an initrd in order to keep running a separate / usr fs, I recall quite a number of gentoo user voices in this M/L alone objecting to the changes. What is an edge use case for Fedora, is/was not so much of an edge use case in Gentoo. Gentoo did not *have* to follow upstream changes, but yet again this could probably bring its ultimate stagnation/demise as devs would be spread too thin to keep developing Gentoo in a deviating path from the rest of the Linux trajectory. Having used and still using other binary distros I'm grateful Gentoo's still here, but would really prefer it did not bend itself out of shape to accommodate solutions to problems I and others do not have, or when we do we may not even use Gentoo to solve them. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Tue, Aug 6, 2019 at 7:41 PM Grant Taylor wrote: > > On 8/6/19 10:28 AM, Rich Freeman wrote: > > An initramfs is just a userspace bootloader that runs on top of linux. > > I disagree. > > To me: > > · A boot loader is something that boots / executes a kernel with > various parameters. > · An initramfs / initrd (concept) is the micro installation that runs > under the kernel that was booted (by the boot loader). Bootloaders are just programs that run other programs, ultimately. We can argue all day about what kinds of programs count as each. But, there is no point arguing definitions. > The initramfs / initrd micro installation does the following: > > 1) fulfills prerequisites (e.g. loads requisite drivers, initializes > networking for and discovers storage, decrypts block devices) > 2) mounts root (and some other) file systems > 3) launches additional init scripts. So, an initramfs doesn't actually have to do ANY of those things, though typically it does. > None of those steps include booting / executing an alternate kernel. Nothing prevents an initramfs from booting an alternate kernel actually, though if it does it will need its own root filesystem initialized one way or another (which could be an initramfs). Linux bootstrapping linux is basically the whole premise behind coreboot. > > > and you don't need to have cruft all over your filesystem to do it. > > Actually yes you do need that cruft. Sure, but you don't need it ALL OVER YOUR FILESYSTEM. Some of the proposed solutions in this thread involved sticking stuff in /bin and so on. An initramfs is nicely bundled up in a single file. > If anything, having an initramfs / initrd means that you're going to > have an additional copy of said core system files in a slightly > different format (initramfs / initrd) that's not usable by the main system. Absolutely true, which means it won't interfere with the main system, as opposed to sticking it in /bin or somewhere where it might. > > and they make your bootstrapping process infinitely flexible. > > Nope. I don't agree. > > There have been many things that I've wanted to do in the past 20 years > that initramfs / initrd aren't flexible enough to do. Such as? It is a linux userspace. It can literally do anything. > But adding an init script that calls tools on the root file system is > infinitely more flexible. I'm not restricted to doing things that > dracut (et al.) know how to do. You don't need to use dracut (et al) to have an initramfs. In fact, you could create your super root filesystem that does all the fancy stuff you claim you can't do with an initramfs, then create a cpio archive of that root filesystem, and now you have an initramfs which does the job. > If I can boot the kernel, point it at a root disk, and launch an init > system, I can do anything I want with the system. Sure, but only if the kernel can find that disk without any userspace code. What if that disk is on the other side of an ssh tunnel? > Let me say it this way. If I can put together commands to do something, > I can get thee system to do it on boot. I don't have to wait for dracut > to be updated to support the next wiz-bang feature. If you know the commands to do something, why would you have to wait for somebody else to implement them? > > > If you want root to be a zip file hosted on a webserver somewhere > > that isn't a problem. If you want root to be a rar file on a > > gpg-encrypted attachment to a message stored on some IMAP server, > > you could do that too. To make all that work you can just script it > > in bash using regular userspace tools like curl or fetchmail, without > > any need to go mucking around with lower-level code. Then once your > > root filesystem is mounted all that bootstrapping code just deletes > > itself and the system operates as if it was never there (strictly > > speaking this isn't required but this is usually how it is done). > > You need /something/ to be your starting root file system. For most > servers / workstations / VMs / containers, that's a local directory > structure. Actually, for most of these the initramfs is the starting root filesystem (just about all linux server installs use one). Usually it just mounts a simple filesystem on a local disk as root and then pivots. However, an initramfs frees you up from the limitation that it be something that can be passed directly on the command line. > Sadly, I think people have thrust additional (IMHO) largely unnecessary > complexity into the init process just to be able to support more exotic > installations. Then, they have said "We want to be consistent in how we > boot, so we need to use this more complex thing everywhere." To which, > many greybeards have responded "I don't need nor want that on my simple > server." Initramfs is popular because it is way more flexible: 1. You can build a fully modular kernel so that you can use the same kernel on every system but not be loading
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Tue, Aug 6, 2019 at 7:39 PM Ian Zimmerman wrote: > > On 2019-08-06 12:28, Rich Freeman wrote: > > > > Arguing against this trivial (and IMHO, elegant) solution is tilting > > > at windmills. Specially if it is for ideological reasons instead of > > > technical ones. > > > Some of the solutions I've seen tossed out in this thread are more > > complex than just building your own initramfs from scratch. > > > > An initramfs is just a userspace bootloader that runs on top of linux. > > Nobody has any problem with conventional bootloaders, and if you want > > to do anything with one of those you have to muck around in low-level > > C or assembly. > > There is a difference, and that difference is the reason I dislike > initramfs, not one of the other possible reasons you hypothesize. The > difference is that real Unix processes (not just kernel threads and not > just PID 1) survive from the initramfs stage into the "real Unix" > stage. It's like being able to trace matter back before the Big Bang. They only persist if you allow them to. Most implementations I've seen don't leave anything behind. Typically an initramfs will unlink everything inside, kill any stray processes (if it even forks anything in the first place), and then will exec the new init from the previous init. That starts up init as PID 1 with nothing else running, and no trace of the initramfs remaining. But, sure, you can stick a fork bomb in an initramfs and have it create 10GB of junk in the ramfs as well so that you boot up a crippled system if you really want to. Unless something has changed the kernel is actually built with an empty initramfs built-in by default which loads no matter what. So, the framework of an initramfs is always there, and the only thing that changes is whether it does anything. -- Rich
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On 8/6/19 10:28 AM, Rich Freeman wrote: An initramfs is just a userspace bootloader that runs on top of linux. I disagree. To me: · A boot loader is something that boots / executes a kernel with various parameters. · An initramfs / initrd (concept) is the micro installation that runs under the kernel that was booted (by the boot loader). The initramfs / initrd micro installation does the following: 1) fulfills prerequisites (e.g. loads requisite drivers, initializes networking for and discovers storage, decrypts block devices) 2) mounts root (and some other) file systems 3) launches additional init scripts. None of those steps include booting / executing an alternate kernel. Remember that the contents of an initramfs / initrd is a micro instillation that simply includes the minimum number of things to do steps 1–3 above. The initrd is literally an image of a block device with a root file system on it that includes the minimum number of things to do steps 1–3 above. The initramfs is a CPIO archive of the minimum number of things to do steps 1–3 above which get extracted to a temporary location (usually a ram disk). Both an initrd and an initramfs are a micro installation for the purpose of initializing the main installation. They are not a boot loader. Nobody has any problem with conventional bootloaders, and if you want to do anything with one of those you have to muck around in low-level C or assembly. That's because a boot loader, e.g. GRUB, lilo, loadlin, do something different and operate at a lower level than system init scripts. There has been talk of gathering up all the stuff you need from /usr to bootstap everything, and then adding some scripting to mount everything. The proposals have been to shove all that in / somewhere (perhaps even in /bin or /sbin). If instead you just stick it all in a cpio archive you basically have an initramfs, Not basically. That /is/ what an initramfs / initrd contains. and you don't need to have cruft all over your filesystem to do it. Actually yes you do need that cruft. Let's back up and talk about what that cruft is. It's the minimum libraries and binaries required to: 1) Requisite libraries - C library - other similar / minimal / unavoidable libraries 2) Requisite binaries - fsck - mount - networking utilites (for iSCSI / NFS / etc.) - other similar / minimal / unavoidable binaries 3) Scripts to bring the rest of the system up - minimal init scripts to go from a post-kernel-execution (what was traditionally /sbin/init) to launching second stage init scripts To me, all of these things are going to exist on the main installation /anyway/. There is going to be minimal, if any, difference between the version put in the initramfs / initrd and what's in the main / (root). So, to me, what you're calling "cruft" is core system files that are going to exist anyway. If anything, having an initramfs / initrd means that you're going to have an additional copy of said core system files in a slightly different format (initramfs / initrd) that's not usable by the main system. There are already configurable and modular solutions like dracut which do a really nice job of building one, Yes. We've had many different tools in the last 28 years of Linux and longer for Unix for making the management of the boot process simpler. It comes down to loading the kernel from something and starting the kernel with proper parameters (that's the boot loader's job) and starting something (traditionally /sbin/init) from some storage somewhere. and they make your bootstrapping process infinitely flexible. Nope. I don't agree. There have been many things that I've wanted to do in the past 20 years that initramfs / initrd aren't flexible enough to do. But adding an init script that calls tools on the root file system is infinitely more flexible. I'm not restricted to doing things that dracut (et al.) know how to do. If I can boot the kernel, point it at a root disk, and launch an init system, I can do anything I want with the system. Let me say it this way. If I can put together commands to do something, I can get thee system to do it on boot. I don't have to wait for dracut to be updated to support the next wiz-bang feature. If you want root to be a zip file hosted on a webserver somewhere that isn't a problem. If you want root to be a rar file on a gpg-encrypted attachment to a message stored on some IMAP server, you could do that too. To make all that work you can just script it in bash using regular userspace tools like curl or fetchmail, without any need to go mucking around with lower-level code. Then once your root filesystem is mounted all that bootstrapping code just deletes itself and the system operates as if it was never there (strictly speaking this isn't required but this is usually how it is done). You need /something/ to be
[gentoo-user] Re: USE flag 'split-usr' is now global
On 2019-08-06 12:28, Rich Freeman wrote: > > Arguing against this trivial (and IMHO, elegant) solution is tilting > > at windmills. Specially if it is for ideological reasons instead of > > technical ones. > Some of the solutions I've seen tossed out in this thread are more > complex than just building your own initramfs from scratch. > > An initramfs is just a userspace bootloader that runs on top of linux. > Nobody has any problem with conventional bootloaders, and if you want > to do anything with one of those you have to muck around in low-level > C or assembly. There is a difference, and that difference is the reason I dislike initramfs, not one of the other possible reasons you hypothesize. The difference is that real Unix processes (not just kernel threads and not just PID 1) survive from the initramfs stage into the "real Unix" stage. It's like being able to trace matter back before the Big Bang. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Tue, Aug 6, 2019 at 5:54 PM Grant Taylor < gtay...@gentoo.tnetconsulting.net> wrote: [...] > > Arguing against this trivial (and IMHO, elegant) solution is tilting at > > windmills. Specially if it is for ideological reasons instead of > > technical ones. > > Please clarify what "this trivial solution" is. Are you referring to > initramfs / initrd or the 'split-user' USE flag? The trivial solution (IMO) is to use an initramfs. Rich gave a much more elaborated answer. Regards. -- Dr. Canek Peláez Valdés Profesor de Carrera Asociado C Departamento de Matemáticas Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On 8/6/19 9:54 AM, Canek Peláez Valdés wrote: If it's computable it can be done, of course. Therefore it can be done, currently. I don't think nobody has said it absolutely cannot be done. >.< So it sounds like it's a question of /how/ compatible / possible it is. It seems as if there is enough incompatibility / problems that multiple people are comfortable saying that it can't be done on some level. The thing is: 1. How much work implies to get it done. 2. Who is gonna do said work. The answer to 1 is "a lot", since (as someone mentioned in the thread) it involves changing not only the init (nevermind systemd; *ALL* init systems), but all applications that may require to use binaries in /usr before it's mounted. The answer to 2 is, effectively, "nobody", since it requires a big coordinated effort, stepping into the toes of several projects, significantly augmenting their code complexity for a corner case[1] that can be trivially be solved with an initramfs, which it just works. I don't currently feel like I can give a proper response to this. 1) I don't have the time to lab this and try things. 2) I don't want to further hijack this thread and start discussing what precisely is and is not broken. 3) I question — from a place of ignorance — just how much effort there is for #1. Arguing against this trivial (and IMHO, elegant) solution is tilting at windmills. Specially if it is for ideological reasons instead of technical ones. Please clarify what "this trivial solution" is. Are you referring to initramfs / initrd or the 'split-user' USE flag? -- Grant. . . . unix || die
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Tue, Aug 6, 2019 at 11:54 AM Canek Peláez Valdés wrote: > > Arguing against this trivial (and IMHO, elegant) solution is tilting at > windmills. Specially if it is for ideological reasons instead of technical > ones. > ++ Some of the solutions I've seen tossed out in this thread are more complex than just building your own initramfs from scratch. An initramfs is just a userspace bootloader that runs on top of linux. Nobody has any problem with conventional bootloaders, and if you want to do anything with one of those you have to muck around in low-level C or assembly. There has been talk of gathering up all the stuff you need from /usr to bootstap everything, and then adding some scripting to mount everything. The proposals have been to shove all that in / somewhere (perhaps even in /bin or /sbin). If instead you just stick it all in a cpio archive you basically have an initramfs, and you don't need to have cruft all over your filesystem to do it. There are already configurable and modular solutions like dracut which do a really nice job of building one, and they make your bootstrapping process infinitely flexible. If you want root to be a zip file hosted on a webserver somewhere that isn't a problem. If you want root to be a rar file on a gpg-encrypted attachment to a message stored on some IMAP server, you could do that too. To make all that work you can just script it in bash using regular userspace tools like curl or fetchmail, without any need to go mucking around with lower-level code. Then once your root filesystem is mounted all that bootstrapping code just deletes itself and the system operates as if it was never there (strictly speaking this isn't required but this is usually how it is done). I doubt we'll see a /usr merge anytime soon, or any huge rush to break a separate /usr completely without an initramfs. However, there are already use cases known where a separate /usr can cause problems without either an initramfs or some kind of early-boot shell script (there have already been solutions tossed out for that which are much simpler than the ones in this thread). The biggest example I've heard is bluetooth keyboards - that was what made most of the zealots give up on supporting anything that could possibly be needed for bootstrapping being in /, as bluetooth has a bunch of deps and at that point you might as well shove gnome in /bin. So, for the forseeable future your system probably won't break if you are using a separate /usr, but if it does the policy has been established for a long time that nobody is obligated to fix it (nor are they prohibited from doing so). Really, though, you should take the time to appreciate an initramfs whether you decide to use one or not. They're a really elegant solution to the problem. Sometimes I think that half the objection is due to the fact that they use cpio which is a bit obscure - if they were tarballs people would be tearing them apart and playing with them more. -- Rich
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Mon, Aug 5, 2019 at 9:38 PM Grant Taylor < gtay...@gentoo.tnetconsulting.net> wrote: [...] > 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. If it's computable it can be done, of course. Therefore it can be done, currently. I don't think nobody has said it absolutely cannot be done. The thing is: 1. How much work implies to get it done. 2. Who is gonna do said work. The answer to 1 is "a lot", since (as someone mentioned in the thread) it involves changing not only the init (nevermind systemd; *ALL* init systems), but all applications that may require to use binaries in /usr before it's mounted. The answer to 2 is, effectively, "nobody", since it requires a big coordinated effort, stepping into the toes of several projects, significantly augmenting their code complexity for a corner case[1] that can be trivially be solved with an initramfs, which it just works. Arguing against this trivial (and IMHO, elegant) solution is tilting at windmills. Specially if it is for ideological reasons instead of technical ones. Regards. [1] I firmly believe that's the situation nowadays. -- Dr. Canek Peláez Valdés Profesor de Carrera Asociado C Departamento de Matemáticas Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
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
[gentoo-user] Re: USE flag 'split-usr' is now global
If I correctly remember the post by Lennart that spawned this entire debate, there were and are genuine technical reasons why a separate /usr filesystem doesn't really work anymore. Perhaps fixable _if_ all package developers (other than init) paid attention but that's not going to happen. Now of course there is some leap from the above to making /bin and /usr/bin the same _directory_. AFAIK there is no good reason for that other than making it easier to write initscripts (or units). I'm not going to opine how good a reason is that :P Myself, I just have /usr on the rootfs. I don't have an initramfs; when I need a "rescue" environment I boot from a USB stick, not necessarily gentoo. Devuan seems to be the best for this kind of thing nowadays. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
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
such decisions. Only the impacts of such decisions on gentoo in particular.
> > Sure, but for how much longer?
>
> /me looks around for something that he must have missed.
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). 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.
> 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.
>
> > 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.
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.
> 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 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.
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.
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).
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. One might argue you
still retain the option of using a separate /usr, but with the
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
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
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
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
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On 2019-08-04 20:01, Dale wrote: It was discussed on -dev in at least a couple threads I think. I sort Thanks for that good hint. I did browse through the archives. -- Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
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? 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. 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*! 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. 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. 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. -- Grant. . . . unix || die
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Sunday, 4 August 2019 18:07:41 BST Ian Zimmerman wrote: > On 2019-08-04 12:29, Mick wrote: > > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ > > > > Essentially the historical reasons for having a lot of separate > > directories/ fs/partitions/disks are becoming obsolete and many of > > them are due to merge, changing the baselayout. I assume the move to > > profile 17.1 to deal with the various /lib directories was the start. > > I know about the history as it relates to Unix and Linux in general. In > fact I think I've read that article long ago. But the question is > what's up in gentoo. I suspect another potentially painful migration is > on the horizon; it would be good to know the speed we're moving toward > the horizon :-) 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. 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. 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. Retrograde steps like being forced to use an initramfs just for retaining a separate /usr partition, should not be the way gentoo evolves. Setting up a USE flag to accommodate such changes would be more agreeable for many gentoo users, rather than changing the default set up. 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. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
Ian Zimmerman wrote: > On 2019-08-04 12:29, Mick wrote: > >> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ >> >> Essentially the historical reasons for having a lot of separate >> directories/ fs/partitions/disks are becoming obsolete and many of >> them are due to merge, changing the baselayout. I assume the move to >> profile 17.1 to deal with the various /lib directories was the start. > I know about the history as it relates to Unix and Linux in general. In > fact I think I've read that article long ago. But the question is > what's up in gentoo. I suspect another potentially painful migration is > on the horizon; it would be good to know the speed we're moving toward > the horizon :-) > It was discussed on -dev in at least a couple threads I think. I sort of followed it and my take is, when set to on, which I think it is by default, everything stays as it is now. Could that change later on, possibly. I suspect given the change being pretty large, if it does there will be a news item about it . Of course, that would be discussed in advance on -dev as well. One way to get a heads up on this sort of thing, subscribe to -dev and follow the threads that interest you, about upcoming changes at least. That's why I subscribe to -dev myself and have done so for years. I ignore a lot of it but the things that I think might affect me, I tend to read those so as to figure out how it might affect me and can even know the path going forward or how to work around it. Just a thought. Dale :-) :-)
[gentoo-user] Re: USE flag 'split-usr' is now global
On 2019-08-04 12:29, Mick wrote: > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ > > Essentially the historical reasons for having a lot of separate > directories/ fs/partitions/disks are becoming obsolete and many of > them are due to merge, changing the baselayout. I assume the move to > profile 17.1 to deal with the various /lib directories was the start. I know about the history as it relates to Unix and Linux in general. In fact I think I've read that article long ago. But the question is what's up in gentoo. I suspect another potentially painful migration is on the horizon; it would be good to know the speed we're moving toward the horizon :-) -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
