Quoting Adam Borowski (kilob...@angband.pl): > Systemd is bad, but dropping the pretense that following the needs of _one_ > particular stone-age PDP install is sound design is not bad.
It would be illogical to assert that the only conceivable justification for separate /usr was Thompson & Richie's 1971 need to spread a UNIX system across a pair of 1.5MB KR05 disk packs. I hope you're not asserting that? I would hope and expect that, 46 years further on, people would be implementing that split to further their 2017 needs, not Thompson & Richie's 1971 ones. > Of course, as always our dear Lennart does it wrong (it'd be much better to > follow Hurd instead and use /bin /sbin /lib), but it doesn't make split /usr > without an initrd any better. Watch the goalposts, folks: There's about to be moved. A moment ago, Adam was asserting that a /usr split no longer makes sense. He's about to switch arguments on the fly, asserting instead that it doesn't make sense as a _distro policy goal_. Observe the switcheroo: > Today, any system where you can realistically install a general-purpose > distribution has multiple GB of disk space. There's no gain to put / and > /usr on separate filesystem.... The second sentence doesn't really make sense, and is demonstrably untrue in isolation (as I will illustrate below). However, I'll bet if I challenged it, Adam would fall back on the first sentence, and frame the discussion as about 'install[ing] a general purpose distribution'. Et voila, goalpost relocation! Distributions are often obliged to make one size fit all, one policy not suck overmuch for all installing users. I, on the other hand, am not. I want my system's primary /bin and /sbin contents (specifically, the utilities for fsck, partitioning, backup, restore, mkfs, and similar) to be functional even if /usr for some reason cannot be mounted, or cannot be relied upon, at bootup. Where some of those utilites have been IMO erroneously compiled to have dynamic dependencies on /usr by distro packages, I create local $FOO-static packages to replace them. A normally quiescent / partition (given that, on my servers, I mount /usr, /var, and /home from other filesystems) is highly unlikely to be exposed to filesystem damage, and there is significant value in knowing that it will be usable by the superuser to repair, remake, backup, and restore the other filesystems. And yes, if that were not possible for some reason, I could doubtless PXE boot a maintenance ISO and use that instead -- but it's nonetheless worth some small amount of care and work to me to ensure that / can be used that way under pretty much all circumstances, and I consider that a normal expectation for a Unix system that I see no reason to cease expecting. And I expect my server systems to be able to boot with simple boot chains that includes kernels locally compiled by me appropriately to my system's specific hardware and needs, eliminating the need for an initramfs -- because I prefer that architectural simplicity. Objections that my approach doesn't scale to general-purpose distribution installers are unresponsive to my point. What I state is that I have what I consider a rational use-case for separate /usr without an initramfs for my server systems, and it's irrelevant to my point whether Devuan or any other distribution decides to facilitate creation of that specific configuration out of the box. I didn't _say_ this is something distro installers should do. All I said is that people claiming 'there's no gain' to such a configuration are grossly mistaken. (To reiterate what I said before: I am in no way addressing matters of policy of this or any other distribution.) > I don't get why you'd want to keep moving things around on the real > system if you can isolate it into initrd. OK, I believe you, Adam. You don't. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng