On Sun, Nov 18, 2012 at 05:16:18PM +0200, Samuli Suominen wrote: > I'm still happy enough with building udev out from systemd tree and > letting sep. /usr consept from 90s to finally die in favour of > simplifying the system.
It's from a lot earlier than the 90s. Perhaps we should get rid of pipes, too- they're /so/ 1970s. Torvalds expressed it well[1]: You made the statement that you want to get away from 30 years of history, but the fact is, "30 years of history" is a damn good argument for "that thing worked". > The BIOSes have been upgraded last century to support booting from > larger partitions, the need has long past. > Nobody has ever provided a valid reason for using sep. /usr in the ML > either. > So at the same time as you have never heard a valid reason, the need (which you have never understood) is long past? Pfft. To reiterate again: many of us are used to keeping /usr on a separate partition for security and backup purposes (other use-cases for a separate partition include mounting /usr over NFS, or a common partition for virtual machines.) I'm sure other people would have more. Irrespective, it should be about mechanism, not policy, and certainly not about breaking existing setups. Many of the advertised benefits of the "merge /bin and /sbin to /usr" concept are in fact just benefits of having a separate /usr partition, though of course they're presented as new and unique to the merge. So, if you accept those as benefits, you cannot logically deny them as benefits of a traditional /usr split. Further, as one user pointed out[2]: "I'd be more likely to just stick /usr back on / than create an initramfs - it was only because the LVM guide recommended that /usr go on its own partition that I now face this situation." We were given a simple requirement ages ago: udev requires /usr and /var (and going forward may require /opt for 3rd party drivers) mounted before it starts, not for udev itself but for helper scripts that it may call. Why get bogged down in anything else? The recommended (which became "supported") method to do this was to use an initramfs, since apparently any chicken-and-egg problems (such as requiring a udev-initiated device to mount /usr) are easier to handle there. (Note that no-one has ever provided a description of how they did that, eg for their bluetooth keyboard, so that the issues, and how they are addressed, could be made more transparent to everyone.) A few us are happily running initramfs-less machines by fulfilling the requirement with a couple of patches to openrc initscripts[2]. (It's been working fine here since last August.) This works in the case where you didn't need an initramfs before, ie have modules for local-disks and filesystems built-in, root not on LVM or encrypted, but other partitions might be-- which includes LVM users who followed the Gentoo docs. If that's not enough, there is *already* a forked udev version which quite a few users have been using[3] and reporting success with. I'd hope the new fork would just collaborate with them, but it's entirely up to them what they do. All of this argues that, irrespective of your views of the layouts admins prefer to use, they will still use them regardless, and indeed users will put in the work you yourself told them to.[4] I really don't understand why people are getting beat up on, just for going ahead and doing what they've been told to: provide code for an alternative. If a Gentoo developer doesn't understand what a Gentoo project means, that's his problem. Nor should Gentoo projects suddenly change what they are because "the internet" doesn't understand them. That's a ridiculous basis for any change. The thing none of the proponents of an initramfs, with no other support for a separate /usr (apart from busybox sep /usr which does NOT fulfil the requirements presented by Chainsaw, which Council voted to approve before: for a start it doesn't handle /usr on LVM), have ever answered is: How do you deal with the mismatch problem? That is, when you have programs or libs upgraded, just as part of normal system upgrades, and they are now different, potentially incompatible, to the initramfs. (The potential exists, therefore it must be addressed for a solution even to be considered as robust.) Do you now need another script to run after every emerge to check that files in your initramfs are in sync? After all, we've been told the initramfs is "the new root": iow that we should think of it as our rescue system, so this matters. At the same time, we've been told "it's only a few hundred kilobytes at most." That contradiction has never been answered, either. [1] http://lwn.net/Articles/492134/ [2] http://forums.gentoo.org/viewtopic-t-901206.html [3] http://forums.gentoo.org/viewtopic-t-934678.html [4] http://forums.gentoo.org/viewtopic-p-6987380.html#6987380 -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
