On Thu, Mar 29, 2012 at 10:43 AM, Neil Bothwick <n...@digimed.co.uk> wrote: > On Thu, 29 Mar 2012 10:21:15 -0400, Michael Mol wrote: > >> > That, IMO, is the problem with the current filesystem layout. The >> > split between / and /usr is anything but well-defined. Putting things >> > in different boxes based on their function is good practice. Doing it >> > based on some arbitrary size limit on the box is not. >> >> Except that's not what people are doing. According to what I've read, >> that was the original rationale a couple decades ago, but that hasn't >> been the driving case for it for a long time, and pointing to it in a >> modern context is silly. > > No, that's not the reason for doing it now.
For the sake of sane conversation, then, don't use phrases like "Putting things in different boxes based on their function is good practice. Doing it based on some arbitrary size limit on the box is not." unless it has present context. Referencing an environmental constraint from twenty years ago in current-context discussion about system engineering only clouds the issue. This is part of the problem around this whole conversation dating back to *last summer*; things are referenced outside of their useful context, are presumed to be part of the current context, and get mixed in. It all becomes a confusing mess. > The reason for doing it now > has been applied to the previous solution (generally a bad idea) and is > aimed at making / a self-contained bootable system, which is a movable > target as hardware evolves. I don't think I've seen this adequately described or explained, honestly. How is the target moving? If someone wants to put / on a filesystem that the kernel doesn't have automagic support for, I can see that. Otherwise...not really. > >> These days, you put things on different mount >> points because you want different underlying characteristics either in >> the filesystem or its underlying block device. > > And for the vast majority of use cases, separating /bin and /usr/bin does > not make much sense. For the vast majority of use cases, having more than one display or keyboard doesn't make sense, either. For the vast majority of use cases, one shouldn't need more than one desktop environment installed. For the vast majority of use cases, one shouldn't need more than one optical drive, or more than one USB stick, or more than one authentication backend. That doesn't mean those use cases should be discarded. It means the system should be designed to be flexible. It makes about exactly as much sense for /bin and /usr/bin to be separate directories as it makes sense to mirror the bulk of an OS into a cpio blob that will be loaded into RAM. The initramfs likely won't even fit into some production systems' RAM. I know a talented professional sysadmin/IT guy who has most of his production VMs running some variant of RHEL or CentOS, with only 64M of RAM apiece. Because that makes *sense* when physical RAM may be cheap, but your virtualization vendor bilks you for the difference. So, OK. System bloats again, we can deal. We've been dealing with increasing RAM, disk and CPU requirements for decades. We've even stopped deriding Microsoft for having a bloated platform, given that we can't fend off the bloat ourselves. We eat some crow and move on. Apple and Android's lightweight-by-comparison 'our way or the highway' platform mentalities gain traction and outperform us. So where do we go from here? We have an initramfs which is painfully difficult to keep up to date by hand, as more and more uber-cool things will evolve dependencies on being present early-on. We'll *need* an automated means of keeping the initramfs up-to-date, because not everything supports static linking, and hand-walking the dynamic linking chain is crazy talk. Which means automated tools. These automated tools are going to have to deal with at least as bad an issue of moving targets as keeping / bootable was; they're a full layer of abstraction away from the main system than / was. > >> The gripe about the filesystem layout strikes me as a "it works, but >> it isn't clean or elegant" complaint. That means changing it is change >> for change's sake. And we're going to experience these growing pains >> tenfold as the consequences of that play out. > > It's never been clean or elegant, but it was tolerated and worked around. > Now those that are trying to work around it have said they are no longer > going to do so, which is their choice. I love how this is described as "hey, the decision has been made. It's here to stay." I love how the people described as They are treated as infallible, and the decisions perfect and final. There have been dozens of intelligent suggestions coming from intelligent and well-meaning people, including people making arguments in good faith. They were told they have to either bend over or code. And when they started coding, they got mocked. It's really only going to be upstream's choice until someone takes the choice away from them, either from users migrating away to the point where their paycheck is in danger, or the codebase forking and having the stupid thing done *right*. > If the separate /usr had been > allowed to die when 20MB hard disks were around, this whole situation > would never have arisen. Perhaps. But then perhaps the dozens of incredibly useful systems and new use cases would never have cropped up, either. > The trouble with shit hitting the fan is that the longer you wait the > more there is to spread around :( It was all very nicely concentrated in one place. It could have been dealt with in one place, where a bunch of people very aware of the bulk of the picture could try to find a good solution to a sticky problem. Instead of cleaning up all the shit while it sat in a concentrated place, it got flung out in all directions, increasing the burden on everyone who's actively involved in the bleeding edge areas of system usage and software development. This is going to slow down use and development of anything that depends on those bleeding edges, which is where interesting and new things happen. This will definitely be killing off things which held promise. -- :wq
