Re: [gentoo-dev] Opinion against /usr merge
On Wed, 18 Jul 2012 20:27:29 +0200 Michał Górny wrote: > > 3. More support for mdev; e.g. https://wiki.gentoo.org/wiki/Mdev > > and (still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB > > The next challenge is "custom mdev rules", which should be do-able. > > I don't think we should give more support to building a system from > a statically linked rescue suite tool. Could you try and be a bit more respectful, please? Bashing other people's preferred tools of the trade usually amounts in horrible flame wars and sometimes ends in people forking their very own sibling projects (through spite or excommunication). Thanks, jer
Re: [gentoo-dev] Opinion against /usr merge
On 07/18/2012 08:27 PM, Michał Górny wrote: > I don't think we should give more support to building a system from > a statically linked rescue suite tool. For people wanting to shave some seconds from their boot openrc using busybox is quite handy and should be used as default IMHO. lu
Re: [gentoo-dev] Opinion against /usr merge
On Thu, 19 Jul 2012 07:05:39 -0400 Rich Freeman wrote: > As others have mentioned, coreutils doesn't impact the initramfs much > anyway, though other tools like mdadm/lvm/etc are more likely to. > > I think the more practical issue is that it isn't straightforward to > do in an automated way. I suppose we could keep an always-up-to-date > kernel and initramfs SOMEWHERE, but that won't necessarily be where > the user boots it from. Also, we need flexibility as users tend to > tweak these things - dracut has lots of options for how the initramfs > is built, users might use any of several initramfs implementations, > and the kernel config is frequently tweaked, and doesn't always work > if you just do a make oldconfig. Usually the way other distros make > all of this work is by making everything generic and not support > configurability. > > Rich > For me, the issue isn't so much that it's *hard* to rebuild an initramfs as that it's not obvious *when* to do so. For the kernel, this is a trivial problem: when sys-kernel/gentoo-sources bumps, rebuild the kernel. For an initramfs, when do I rebuild? When there's a new, what? Coreutils? Mdadm? LVM? Glibc? Busybox? Something-firmware? What about any less-obvious libraries they might link to, like zlib or something? All of those things are presumably in my initramfs, but there's no canonical list I'm aware of that tells me "if one of the packages in this list updates, you must rebuild your initramfs if you wish to take advantage of the upgrade". Chris
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 07:04:15PM -0700, Olivier Cr?te wrote > The rescue system should be entirely separate from the main system, so > it survives mishandled upgrades. So having that should not hinder how > your main system is built. So you should have it as a separate partition > or you can even have it an initramfs (ie, in a single file on the main > system). If you want *REALLY* "entirely separate from the main system", you should be looking at a "rescue CD" or bootable USB key. That's about as safe as you can get. -- Walter Dnes
Re: [gentoo-dev] Opinion against /usr merge
On 07/18/2012 02:25 PM, Michael Mol wrote: > 1) There are no truly mature tools for automatically generating and > installing an initramfs based on system requirements. Canek likes to > recommend dracut, which still isn't marked stable. I've gotten stable > genkernel to work reasonably, but its error reporting is terrible. Please file a bug report and CC me on it. I will be more than happy to improve this for you. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 4:05 PM, Alec Warner wrote: > > I'm not really following your logic here, so forgive me. I completely > understand why folks do not say, rebuild their kernel when it is > updated (kernel configs are annoying.) > > However lets say I have coreutils in / and coreutils in my initramfs. > I upgrade coreutils from v1 to v2. Are you saying that you are too > afraid to update coreutils in / and then also update it in the > initramfs (probably by running $TOOL to copy coreutils from / to > initramfs-root.) As others have mentioned, coreutils doesn't impact the initramfs much anyway, though other tools like mdadm/lvm/etc are more likely to. I think the more practical issue is that it isn't straightforward to do in an automated way. I suppose we could keep an always-up-to-date kernel and initramfs SOMEWHERE, but that won't necessarily be where the user boots it from. Also, we need flexibility as users tend to tweak these things - dracut has lots of options for how the initramfs is built, users might use any of several initramfs implementations, and the kernel config is frequently tweaked, and doesn't always work if you just do a make oldconfig. Usually the way other distros make all of this work is by making everything generic and not support configurability. Rich
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 7:04 PM, Olivier Crête wrote: > On Wed, 2012-07-18 at 18:24 -0700, Matthew Marlowe wrote: > >> - It would be nice if the rootfs used a snapshot based filesystem and >> if the bootloader was intelligent enough to easily allow admins to >> boot to older snapshots as an expectation for any standard modern unix >> system. > > One of the reasons to put everything in /usr is to allow using a > snapshot based FS, so you can run a system where /usr is read-only and > where when you can do all upgrade atomically by writing your changes to > a read-write snapshot and then switch all at once. So you never have any > half-upgraded package on your system. > I understand that RHEL is promoting this system management model, but I'm not sure it is any way superior than other models that do not require RO /usr. Many enterprises today solve the same issue via automation with puppet, active traffic management via LVS/HA/Load Balancers, or replace /usr snapshots with virtualization where a new VM snapshot or clone is upgraded and then replaces the active VM. Therefore, I'm not convinced we should promote /usr/bin and /usr/sbin over /bin and /sbin. It is a point in their favor to give more flexibility but the simplicity of also just removing /usr would also be compelling if our goal afterall is to simplify the FHS. > >> - OK with merging / and /usr, but in that case...why not just move >> everything in /usr to /...but limit /sbin to system binaries and /bin >> to user ones? This would be horrible for migrations though and >> possibly confuse many scripts. > > The idea of putting everything in /usr instead of / is that you can then > make /usr read-only and you can share /usr between multiple systems, > while / is read-write and contains /root and /etc. > Most enterprises that need the ability to make /usr RO for canonical server configs could just as well get by with automated configuration management tools (e.g. puppet) and smart hypervisors/SAN storage. This allows deployment of new servers within minutes and it reflects at least the true reality that a true controlled system state is a snapshot of server config files, virtual hardware, and all binaries. Just making /usr RO is a cheat that might work well for long lived binary distributions that require major version upgrades anytime software packages update their config behavior dramatically. I haven't found it very helpful for source type systems like Gentoo. Of course, others may disagree. >> - NOT OK with making systemd the default init system anytime in the >> next few years, it is way too immature and like most major system >> software changes...probably will take much longer before it really has >> the standing to propose being a new standard. > > I fully expect systemd to be the init system of the next iteration of > RedHat Enterprise Linux, which is probably the most "enterprise" of all > distributions, with the most QA and support and everything. It's not a > side project of dude of his basement, it has the full support of a large > team of people at RedHat. There has probably already been more testing > done on systemd today than on OpenRC... > Well, we know that systemd will be in the next RHEL release - it was in their recent roadmap presentation. However, that release would be RHEL7 and most established servers are RHEL5 now and RHEL6 is still relatively early in deployment. It will be a few years before most RedHat customers can say whether systemd was a good move for RHEL. And, RedHat has made changes in the past that while supported might not become the default config for other distributions (e.g. SE Linux). I don't see that we need to assume now that systemd will define the default Linux ecosystem in the future, even if it becomes widely deployed on RedHat systems..
Re: [gentoo-dev] Opinion against /usr merge
On Wed, 2012-07-18 at 18:24 -0700, Matthew Marlowe wrote: > > It would be nice if a sensible structure could be proposed and > > agreed by ALL Linux distributions (coordinated with BSD). > > > > +1 > > If a new file system standard is required, my preferences based on a > history of what is worked and changed over the last 20-30 years would > be: > > - OK with requiring / and /usr on the same FS. This has become common > practice with virtualization and small system deployments, and I > haven't seen any compelling advantage for keeping separate on larger > boxes. No one proposes that, the only requirement that you have for modern Linux to work well is that if /usr is on a separate partition, you need to mount it before starting your main system (ie, from an initramfs). > - NOT OK with limitation on allowing /var, /opt, /home, or any other > common server mount points to require use of initramfs/initrd. There > is enough disagreement as to the reliability and ease of maintenance > of initramfs/initrd that it should not be needed for common server > deployments. This is clearly not needed, /run was even invented to allow /var to be mounted later. > - It would be nice if the rootfs used a snapshot based filesystem and > if the bootloader was intelligent enough to easily allow admins to > boot to older snapshots as an expectation for any standard modern unix > system. One of the reasons to put everything in /usr is to allow using a snapshot based FS, so you can run a system where /usr is read-only and where when you can do all upgrade atomically by writing your changes to a read-write snapshot and then switch all at once. So you never have any half-upgraded package on your system. > - Ideally, server motherboards would come with flash based storage > where sysadmins could install rescue environments as part of a normal > unix install, and that the boot loader or bios would be smart enough > to provide the option to boot from it automatically whenever a normal > boot failed. > - NOT OK with removing the distinction between user and system > binaries. Essential binaries required to boot and troubleshoot system > problems should be located separately from user binaries. Security > sensitive or paranoid admins should be able to make the system binary > path read-only or completely remove the user binary directory from > roots PATH if they so wish. The rescue system should be entirely separate from the main system, so it survives mishandled upgrades. So having that should not hinder how your main system is built. So you should have it as a separate partition or you can even have it an initramfs (ie, in a single file on the main system). > - OK with merging / and /usr, but in that case...why not just move > everything in /usr to /...but limit /sbin to system binaries and /bin > to user ones? This would be horrible for migrations though and > possibly confuse many scripts. The idea of putting everything in /usr instead of / is that you can then make /usr read-only and you can share /usr between multiple systems, while / is read-write and contains /root and /etc. > - NOT OK with making systemd the default init system anytime in the > next few years, it is way too immature and like most major system > software changes...probably will take much longer before it really has > the standing to propose being a new standard. I fully expect systemd to be the init system of the next iteration of RedHat Enterprise Linux, which is probably the most "enterprise" of all distributions, with the most QA and support and everything. It's not a side project of dude of his basement, it has the full support of a large team of people at RedHat. There has probably already been more testing done on systemd today than on OpenRC... > - What other elements can new filesystems like btrfs offer that should > be considered? ext3/ext4 has worked great with the older > standards...but it essentially mimicked the capabilities of older > file-systems that the original unix standards were based on. Btrfs > might change our expectations. I'm assuming that btrfs will be the > standard production fs in a few years. The big thing that btrfs brings is snapshots and subvolumes... So it makes it possible to do atomic upgrades and such. Also, you can have "apps" be subvolumes and also handled atomically. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 08:27:29PM +0200, Micha?? G??rny wrote > On Wed, 18 Jul 2012 11:35:02 -0400 > "Walter Dnes" wrote: > > > 3. More support for mdev; e.g. https://wiki.gentoo.org/wiki/Mdev > > and (still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB > > The next challenge is "custom mdev rules", which should be do-able. > > I don't think we should give more support to building a system from > a statically linked rescue suite tool. Busybox is a well-supported lightweight replacement for udev and most of coreutils, and also happens to double up as a rescue tool. See my reply to Jason A. Donenfeld for more. BTW, "static" is an optional USE flag for busybox. -- Walter Dnes
Re: [gentoo-dev] Opinion against /usr merge
On 07/19/12 03:05, Rich Freeman wrote: > On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol wrote: >> AFAIK, neither genkernel nor dracut were expected to get tied to the >> Gentoo update process. Has that changed? > We don't even update kernels as part of the regular update process, > let alone initramfs systems. > > In general you update them together. > > The only issue I could see is if problems arise if you have a > different version of udev in your initramfs than on your system. I > don't know if that actually causes problems. For the most part after > the system is booted the initramfs is done its job. > > If some package did need a kernel/initramfs/etc to be updated it > should be the subject of news or an ewarn unless it becomes routine > practice. I don't think we want the system to start touching these > things without operator intervention unless we make it really > bulletproof like they do on big distros (the only reason they can is > they have one-size-fits-all kernels and initramfs designs). > > And here's an epic failure mode waiting to happen - what if the kernel is not stored in /boot ? I can think of at least two common setups where that happens. One is virtual machines (Xen for example usually stores the kernel outside the guest filesystem), the other is systems with full-disk encryption where you don't have a bootloader on the local disk. Ah, who would have guessed that there are linux installs that are not single-disk desktops!
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 08:06:41PM +0200, Jason A. Donenfeld wrote > On Wed, Jul 18, 2012 at 5:35 PM, Walter Dnes wrote: > > > > 3. More support for mdev; e.g. https://wiki.gentoo.org/wiki/Mdev and > > (still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB The > > next challenge is "custom mdev rules", which should be do-able. > > > Interesting. Can you talk more about the benefits of mdev in > non-embedded systems? Why would I want to use this instead of udev > (aside from the /usr dispute). The biggest benefit is that Gentoo wouldn't become a Redhat-based distro. You can compile Redhat (or Centos) from source with SRPM packages if you wanted a Redhat-based build-from-source distro. They proclaim that udev will not require systemd for the time being. But given how cavalierly they broke 20 years of linux file hierarchy, I'm skeptical of their promises of continued backwards compatability. And what else do they have coming down the pike? What's next to get broken? Alpine Linux http://alpinelinux.org/ is busybox-based, so it can be done. A major problem for me is that it also uses uclibc. It does do X11, e.g. GNOME, XFCE, etc), but uclibc rules out my Nvidia card with proprietary drivers. I'm also a paying subscriber of NHL Gamecentre Live, so I need proprietary Flash, which gets broken by uclibc. I've tried Nouveau and Gnash, and they are not ready for primetime. -- Walter Dnes
Re: [gentoo-dev] Opinion against /usr merge
> It would be nice if a sensible structure could be proposed and > agreed by ALL Linux distributions (coordinated with BSD). > +1 If a new file system standard is required, my preferences based on a history of what is worked and changed over the last 20-30 years would be: - OK with requiring / and /usr on the same FS. This has become common practice with virtualization and small system deployments, and I haven't seen any compelling advantage for keeping separate on larger boxes. - NOT OK with limitation on allowing /var, /opt, /home, or any other common server mount points to require use of initramfs/initrd. There is enough disagreement as to the reliability and ease of maintenance of initramfs/initrd that it should not be needed for common server deployments. - It would be nice if the rootfs used a snapshot based filesystem and if the bootloader was intelligent enough to easily allow admins to boot to older snapshots as an expectation for any standard modern unix system. - Ideally, server motherboards would come with flash based storage where sysadmins could install rescue environments as part of a normal unix install, and that the boot loader or bios would be smart enough to provide the option to boot from it automatically whenever a normal boot failed. - NOT OK with removing the distinction between user and system binaries. Essential binaries required to boot and troubleshoot system problems should be located separately from user binaries. Security sensitive or paranoid admins should be able to make the system binary path read-only or completely remove the user binary directory from roots PATH if they so wish. - OK with merging / and /usr, but in that case...why not just move everything in /usr to /...but limit /sbin to system binaries and /bin to user ones? This would be horrible for migrations though and possibly confuse many scripts. - NOT OK with making systemd the default init system anytime in the next few years, it is way too immature and like most major system software changes...probably will take much longer before it really has the standing to propose being a new standard. - What other elements can new filesystems like btrfs offer that should be considered? ext3/ext4 has worked great with the older standards...but it essentially mimicked the capabilities of older file-systems that the original unix standards were based on. Btrfs might change our expectations. I'm assuming that btrfs will be the standard production fs in a few years.
Re: [gentoo-dev] Opinion against /usr merge
In the beginning there were root (/bin) and /usr programs See UNIX Programmer's Manual (Thompson, Ritchie, November 1971). [http://cm.bell-labs.com/cm/cs/who/dmr/manintro.pdf] /usr programs were "not considered part of the UNIX system" [bottom of page ii]. Root (/) contained all the system files and configuration; /usr all the user's files. In the UNIX V7 manuals hosted here: http://plan9.bell-labs.com/7thEdMan/bswv7.html Dennis Rtichie suggests moving binary files from root (/bin) to /usr/bin because it might speed up systems: See page 152 of UNIX Version 7, Volume 2B UNIX Programmers Manual. Hence, he suggests leaving only maintenance binary files in root (see para. 3 under Disk Layout, Pg. 152). The most important remark comes in paragraph 2 of the disk layout page: "There are two considerations in deciding how to adjust the arrangement of things on your disks: the most important is making sure there is adequate space for what is required; secondarily, throughput should be maximised." For me the argument is about what gets mounted in which way. I want to be able to ensure filesystems are mounted to prevent potential privilege escalation. Consequently, I have split my Gentoo system with the following settings. At boot /usr is present in / (on same partition) /tmp is mounted nosuid from a separate partition /var is mounted nosuid from a separate partition /home is mounted nosuid from a separate partition /bin and /sbin programs that do not require root authority are all marked nosuid. None of the executables/configuration files in / or /usr are user-writable. umasks are 077. On my backup server, /home is mounted noexec, nosuid. Personally I like the split between /bin and /usr/bin and /sbin and /usr/sbin - provided ports maintainers stick to an understanding that /bin is for maintenance files and /usr/bin is for user application files (i.e. applications used by users). /sbin and /usr/sbin should segregate root's/system maintenance executables and root's/system application executables. Although I am not sure at all that executables have been so split by recent developers/maintainers (a lot of time has passed)... It would be nice if a sensible structure could be proposed and agreed by ALL Linux distributions (coordinated with BSD). For me, it is a credit to Ken and Dennis' vision that they foresaw the benefit of file permissions, including suid and sgid and the EXCEPTIONALLY BRILLIANT idea of the sticky bit for /tmp. It is incredible that they came up with much of this structure in 1969 - 1978. "Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it." SATAYANA Those querying a separate /usr partition or otherwise might like to peruse UNIX Version 7 UNIX Programmers manual, Volume 2A: UNIX for Beginners (Brian W. Kernighan) Page 46 of this PDF: http://plan9.bell-labs.com/7thEdMan/v7vol2a.pdf I LIKE THE IDEA of a separate /usr partition - but that is from a mounting file-systems perspective rather than relying on the history of UNIX... Live free or die - UNIX. Mike On 18/07/12 18:35, Canek Peláez Valdés wrote: As William pointed out, this is just another silly rationalization done after the fact. But, just for argument's sake, lets suppose that "usr" was named like that because it was the acronym for "UNIX System Resources". *Who cares about that now?* It was 43 years ago. My cellphone is thousands of times faster than the PDP-7 Unix was originally developed for, and it has millions of times more storage. The length restrictions imposed on system directories are completely superfluous now. All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin separated are really instances of the Chewbacca defense [1]. They just don't make any sense.
Re: [gentoo-dev] Opinion against /usr merge
Rich Freeman wrote: > 5. When something goes wrong you can get a dash/bash shell .. > useful even if you don't have firefox+X11 in your initramfs. This is one of the first videographed use cases for coreboot. The initramfs in the video[1] admittedly does not have a browser. Those days, boot flash were up to 2 Mbyte. Today they are up to 16 Mbyte, so a browser can certainly be added. http://www.coreboot.org/Screenshots#LinuxBIOS_with_X_Server_Inside //Peter [1] http://www.youtube.com/watch?v=nuzRsXKm_NQ [1] http://downloads.sourceforge.net/fornix/linuxbios.ogg
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 4:02 PM, Rich Freeman wrote: > On Wed, Jul 18, 2012 at 3:40 PM, Michael Mol wrote: >> So your initramfs doesn't include network tools such as ping, >> traceroute or wget. Fine. Fundamentally speaking, why shouldn't >> someone else's? > > So, an initramfs is just a piece of kernel functionality. You can do > almost ANYTHING in an initramfs, subject to the limitation that it is > stored in RAM without any backing store. Yup. IIRC, it has effectively the same underlying implementation as tmpfs, using always-dirty file cache pages. > > There are lots of reasons to use an initramfs, and the biggest ones > don't pertain much to Gentoo. Here are some of the big use cases: > > 1. One-size-fits-all kernel. You want to support root and /usr on > any filesystem, on any kind of hard drive, or on a SAN, or who knows > where. That either means saying Y to every driver in the kernel, or > saying M and using an initramfs to load what is needed to get to root. > > 2. One-size-fits-all grub config. You put the smarts in the > initramfs, and use filesystem labels and such to identify partitions. > > 3. Use of labels/UUIDs on partitions. When mdadm decides to renumber > half your devices on a whim or you add a drive and everything bubbles > down by one, your system still boots. > > 4. Cleaner mounting of root, ability to fsck on initial mount, etc. > > 5. When something goes wrong you can get a dash/bash shell instead of > a grub shell. The former is clearly more useful even if you don't > have firefox+X11 in your initramfs. > > 6. Support for booting off of stuff that the kernel can't find on its > own, like SANs/etc. That might require network support in the > initramfs, and that usually isn't a big deal. If somebody can spoof > DNS on your fiber channel interface you've got bigger problems. > > Sure, the more you do with the initramfs the bigger the potential > security risks. Most distros don't have users build either kernels or > initramfs which means they can just push updates, but that requires #1 > above, which I think most Gentoo users would not appreciate. I fall into use cases 3 and 5, myself. Incidentally, bash is also network-aware. (Not sure if the default USE flag set allows it, though.) Were I to explicitly add network-aware tools, I'd probably add either ssh/sftp/scp or links. > > However, the initramfs shouldn't leave much of anything running after > it chroots, so the window should be fairly small. So is the window for spoofing DNS responses. That didn't stop DNS hijacking from being fairly easy. (And why there was a large coordinated, cross-vendor effort to add source-port randomization once it was shown to be easy.) Multi-threaded native code has been my day job for the last five years. I may be a bit biased when it comes to race conditions. -- :wq
Re: [gentoo-dev] Opinion against /usr merge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/07/12 04:05 PM, Alec Warner wrote: > [...] However lets say I have coreutils in / and coreutils in my > initramfs. I upgrade coreutils from v1 to v2. Are you saying that > you are too afraid to update coreutils in / and then also update it > in the initramfs (probably by running $TOOL to copy coreutils from > / to initramfs-root.) > > I'm not suggesting that we necessarily do this automatically, just > that people claim 'the tools do not exist to do this now' when in > fact it seems fairly straightforward to do. > > I mean presumably you used $TOOL to build the initramfs once, so > running $TOOL again to generate a new initramfs probably should > not screw you, provided you have control over the configuration of > $TOOL. IIRC, and unless this has changed recently (ie within the last year or two), a genkernel-generated initramfs is built on specific versions of all the tools that genkernel itself ensures is downloaded, ie, *NOT* the same versions as are installed in your / , and often are actually older. You can, of course, change this via /etc/genkernel.conf for each tool. ..so in that particular case, one would want their initramfs regenerated when genkernel gets upgraded (but after /etc/genkernel.conf is etc-update'd) If I remember my hearsay correctly, dracut does build the initramfs from tools on / , though...? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlAHGFAACgkQ2ugaI38ACPCjlAD/Qin9JKK6SFAr/5G2vjgqJmau BATFNwP/nbgtIb5i0rgA/jlEmZFBK9n14GOYzQxi3BJewGhRvi62WAHsX7EMQzDL =HLZG -END PGP SIGNATURE-
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 12:05 PM, Rich Freeman wrote: > On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol wrote: >> AFAIK, neither genkernel nor dracut were expected to get tied to the >> Gentoo update process. Has that changed? > > We don't even update kernels as part of the regular update process, > let alone initramfs systems. > > In general you update them together. > > The only issue I could see is if problems arise if you have a > different version of udev in your initramfs than on your system. I > don't know if that actually causes problems. For the most part after > the system is booted the initramfs is done its job. > > If some package did need a kernel/initramfs/etc to be updated it > should be the subject of news or an ewarn unless it becomes routine > practice. I don't think we want the system to start touching these > things without operator intervention unless we make it really > bulletproof like they do on big distros (the only reason they can is > they have one-size-fits-all kernels and initramfs designs). I'm not really following your logic here, so forgive me. I completely understand why folks do not say, rebuild their kernel when it is updated (kernel configs are annoying.) However lets say I have coreutils in / and coreutils in my initramfs. I upgrade coreutils from v1 to v2. Are you saying that you are too afraid to update coreutils in / and then also update it in the initramfs (probably by running $TOOL to copy coreutils from / to initramfs-root.) I'm not suggesting that we necessarily do this automatically, just that people claim 'the tools do not exist to do this now' when in fact it seems fairly straightforward to do. I mean presumably you used $TOOL to build the initramfs once, so running $TOOL again to generate a new initramfs probably should not screw you, provided you have control over the configuration of $TOOL. -A > > Rich >
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 3:40 PM, Michael Mol wrote: > So your initramfs doesn't include network tools such as ping, > traceroute or wget. Fine. Fundamentally speaking, why shouldn't > someone else's? So, an initramfs is just a piece of kernel functionality. You can do almost ANYTHING in an initramfs, subject to the limitation that it is stored in RAM without any backing store. There are lots of reasons to use an initramfs, and the biggest ones don't pertain much to Gentoo. Here are some of the big use cases: 1. One-size-fits-all kernel. You want to support root and /usr on any filesystem, on any kind of hard drive, or on a SAN, or who knows where. That either means saying Y to every driver in the kernel, or saying M and using an initramfs to load what is needed to get to root. 2. One-size-fits-all grub config. You put the smarts in the initramfs, and use filesystem labels and such to identify partitions. 3. Use of labels/UUIDs on partitions. When mdadm decides to renumber half your devices on a whim or you add a drive and everything bubbles down by one, your system still boots. 4. Cleaner mounting of root, ability to fsck on initial mount, etc. 5. When something goes wrong you can get a dash/bash shell instead of a grub shell. The former is clearly more useful even if you don't have firefox+X11 in your initramfs. 6. Support for booting off of stuff that the kernel can't find on its own, like SANs/etc. That might require network support in the initramfs, and that usually isn't a big deal. If somebody can spoof DNS on your fiber channel interface you've got bigger problems. Sure, the more you do with the initramfs the bigger the potential security risks. Most distros don't have users build either kernels or initramfs which means they can just push updates, but that requires #1 above, which I think most Gentoo users would not appreciate. However, the initramfs shouldn't leave much of anything running after it chroots, so the window should be fairly small. Rich
Re: [gentoo-dev] Opinion against /usr merge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/07/12 03:55 PM, Michael Mol wrote: > On Wed, Jul 18, 2012 at 3:50 PM, Ian Stakenvicius > wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> On 18/07/12 03:47 PM, Michael Mol wrote: >>> On Wed, Jul 18, 2012 at 3:25 PM, Canek Peláez Valdés >>> wrote: On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol wrote: The real benefit is that it allows you to mount any partition, if the tools to mount it live in the same partition. >>> >>> Certainly that's a benefit. >>> >> >> ...don't you mean, "if the tools to mount it live in the >> initramfs" ?? >> >> if the partition isn't mounted I don't see how the initramfs >> will allow you to mount it using its own tools... > > I think you're replying to Canek. I took it to mean that having an > initramfs allows you to mount the very filesystems where you would > _traditionally_ expect to find the tools. E.g., being able to mount > an encrypted /. > Yeah i was.. i just wanted to re-emphasize the point that the tools to mount it need to be on the initramfs (in whatever version or form they were when the initramfs was built), and really have nothing to do with them (including their current and possibly more up-to-date version) living on said partition.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlAHFZUACgkQ2ugaI38ACPAiMAD/eWHxvaZPu1ikYN9ZeClsEWnB pBDgfVPC0UTDeoUOVFcA+gKCmqa+lhs0x+arJhF7AZfWEbYb+jMK+bVxUVgfElR4 =O0O4 -END PGP SIGNATURE-
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 3:50 PM, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 18/07/12 03:47 PM, Michael Mol wrote: >> On Wed, Jul 18, 2012 at 3:25 PM, Canek Peláez Valdés >> wrote: >>> On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol >>> wrote: >>> >>> The real benefit is that it allows you to mount any partition, if >>> the tools to mount it live in the same partition. >> >> Certainly that's a benefit. >> > > ...don't you mean, "if the tools to mount it live in the initramfs" ?? > > if the partition isn't mounted I don't see how the initramfs will > allow you to mount it using its own tools... I think you're replying to Canek. I took it to mean that having an initramfs allows you to mount the very filesystems where you would _traditionally_ expect to find the tools. E.g., being able to mount an encrypted /. -- :wq
Re: [gentoo-dev] Opinion against /usr merge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/07/12 03:47 PM, Michael Mol wrote: > On Wed, Jul 18, 2012 at 3:25 PM, Canek Peláez Valdés > wrote: >> On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol >> wrote: >> >> The real benefit is that it allows you to mount any partition, if >> the tools to mount it live in the same partition. > > Certainly that's a benefit. > ...don't you mean, "if the tools to mount it live in the initramfs" ?? if the partition isn't mounted I don't see how the initramfs will allow you to mount it using its own tools... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlAHE3QACgkQ2ugaI38ACPDQBwD9HOn8skOvLhpPYuqCnH1Nuh7e zefAwVaHDQQsz9vKVeYA/1utNcF2ROdeiHlMfvte4TGH42lo+NOjdM1Ml0wpU9b/ =5AMo -END PGP SIGNATURE-
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 3:25 PM, Canek Peláez Valdés wrote:
> On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol wrote:
>> On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman wrote:
>>> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol wrote:
AFAIK, neither genkernel nor dracut were expected to get tied to the
Gentoo update process. Has that changed?
>>>
>>> We don't even update kernels as part of the regular update process,
>>> let alone initramfs systems.
>>>
>>> In general you update them together.
>>>
>>> The only issue I could see is if problems arise if you have a
>>> different version of udev in your initramfs than on your system. I
>>> don't know if that actually causes problems. For the most part after
>>> the system is booted the initramfs is done its job.
>>
>> The most widely touted benefit I've heard for initramfs is its
>> capability to ease system recovery in case, e.g. a critical filesystem
>> refuses to mount. With recovery roles come recovery tools, which
>> quickly extends network-aware tools and a security attack surface.
>
> The real benefit is that it allows you to mount any partition, if the
> tools to mount it live in the same partition.
Certainly that's a benefit.
> Recovering tools can be
> put in the initramfs, but I don't think nobody actually thinks that
> this is the "most widely touted benefit". Again, citation please.
I'm sorry, but I'm not going to grep through almost a decade of IRC
logs to find every discussion where someone says 'well, just put $tool
in your {initramfs,initrd}.' It's definitely something I've seen a
number of times. I *know* I've heard the line more than once in LUG
meetings, from people who hand-build theirs, but given that's a
local-to-me thing, you probably wouldn't know most of them by name.
>
>> Hence why I tend to feel that if an initramfs is going to become the
>> go-to solution for bootstrapping userland, it's important to consider
>> the difficulties of keeping the packed tools up-to-date; it's not just
>> a bootstrap tool, it's also the first recovery option a sysadmin
>> faces.
>
> If you keep your initramfs synchronized (which is easily done with
> dracut, for example), that problem goes away.
Again, dracut isn't stable, genkernel isn't part of any normal routine
system update, and I hold the same trepidations expressed by Rich
about limitations on circumstances where that's even appropriate.
--
:wq
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 3:20 PM, Canek Peláez Valdés wrote: > On Wed, Jul 18, 2012 at 2:12 PM, Michael Mol wrote: >> On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés >> wrote: >>> On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol wrote: On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner wrote: >>> [snip] > Debian uses initramfs-tools... AFAIK, neither genkernel nor dracut were expected to get tied to the Gentoo update process. Has that changed? >>> >>> The kernel you are running (if you update your machine) is not tied to >>> the Gentoo update process. The *source code* gets installed, but the >>> kernel source remains unchanged in /usr/src/whatever. It's the user >>> responsibility to configure, compile, and install the kernel (and then >>> update LILO, grub-legacy or GRUB2). It can be automated with (ta-da) >>> genkernel, but it's not "tied to the Gentoo update process". >>> >>> I really don't see that much difference with needing to also update >>> the initramfs, if needed. >> >> What if your DNS resolver in your rescue shell has a vulnerability? >> What if wget, links or whatever network tools you use during recovery >> have a vulnerability? >> >> These are tools which are commonly placed in initramfs. > > First of all, none of this has nothing to do with the discussion at > hand. I completely disagree. If you take a step in a direction, you have momentum. So before you take a step in that direction, you should look where that momentum will carry you. > Second, I don't know what kind of initramfs you are familiar > with, but mine has nothing network related, and I don't see *any* > reason to include *anything* network related to an initramfs. So your initramfs doesn't include network tools such as ping, traceroute or wget. Fine. Fundamentally speaking, why shouldn't someone else's? > >>> Because, besides, if your /usr is not in a different partition, you >>> don't even *need* an initramfs. In that case not using an initramfs is >>> supported by all upstreams. >> >> And what of /var? /opt? > > What about them? Again, what it has this anything to do with our > current discussion? See my reply to Michal. > >> The problem with the /usr merge upstream is >> that someone didn't think things through when they pushed it, and the >> same reasoning used to justify it easily justifies changing the way >> /var and /opt are treated. > > That's pure speculation. I'll repeat myself. If you take a step, you have momentum. Before you take a step, you should see where that momentum will carry you. > Nobody has ever suggested merging /opt nor > /var; if I'm mistaken I would love to see even a single link (mail, > blog post, IRC discussion) were it was at least mentioned as a good > idea to do the same with /opt or /var. I'm pretty sure you don't have > any. I don't believe anyone *does* think it's a good idea, but I don't see how the arguments on behalf of a /usr merge don't operate in the same way on /var or /opt. If the argument is flawed for either of those two, I don't see how it isn't equally flawed for /usr. I've never seen where people have examined that in depth. -- :wq
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol wrote: > On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman wrote: >> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol wrote: >>> AFAIK, neither genkernel nor dracut were expected to get tied to the >>> Gentoo update process. Has that changed? >> >> We don't even update kernels as part of the regular update process, >> let alone initramfs systems. >> >> In general you update them together. >> >> The only issue I could see is if problems arise if you have a >> different version of udev in your initramfs than on your system. I >> don't know if that actually causes problems. For the most part after >> the system is booted the initramfs is done its job. > > The most widely touted benefit I've heard for initramfs is its > capability to ease system recovery in case, e.g. a critical filesystem > refuses to mount. With recovery roles come recovery tools, which > quickly extends network-aware tools and a security attack surface. The real benefit is that it allows you to mount any partition, if the tools to mount it live in the same partition. Recovering tools can be put in the initramfs, but I don't think nobody actually thinks that this is the "most widely touted benefit". Again, citation please. > Hence why I tend to feel that if an initramfs is going to become the > go-to solution for bootstrapping userland, it's important to consider > the difficulties of keeping the packed tools up-to-date; it's not just > a bootstrap tool, it's also the first recovery option a sysadmin > faces. If you keep your initramfs synchronized (which is easily done with dracut, for example), that problem goes away. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Opinion against /usr merge
On Wed, 18 Jul 2012 15:12:14 -0400 Michael Mol wrote: > On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés > wrote: > > On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol > > wrote: > >> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner > >> wrote: > > [snip] > >>> Debian uses initramfs-tools... > >> > >> AFAIK, neither genkernel nor dracut were expected to get tied to > >> the Gentoo update process. Has that changed? > > > > The kernel you are running (if you update your machine) is not tied > > to the Gentoo update process. The *source code* gets installed, but > > the kernel source remains unchanged in /usr/src/whatever. It's the > > user responsibility to configure, compile, and install the kernel > > (and then update LILO, grub-legacy or GRUB2). It can be automated > > with (ta-da) genkernel, but it's not "tied to the Gentoo update > > process". > > > > I really don't see that much difference with needing to also update > > the initramfs, if needed. > > What if your DNS resolver in your rescue shell has a vulnerability? > What if wget, links or whatever network tools you use during recovery > have a vulnerability? What if whatever tools you have in rootfs have a vulnerability and they are statically linked so that we don't have to move half of the system into rootfs? > > Because, besides, if your /usr is not in a different partition, you > > don't even *need* an initramfs. In that case not using an initramfs > > is supported by all upstreams. > > And what of /var? /opt? The problem with the /usr merge upstream is > that someone didn't think things through when they pushed it, and the > same reasoning used to justify it easily justifies changing the way > /var and /opt are treated. What with them? /var has a special place of its own, and I don't see why it is brought here. /opt is a defined prefix. Like /usr is. Moving anything into or out of it is a completely separate topic. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 2:12 PM, Michael Mol wrote: > On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés wrote: >> On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol wrote: >>> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner wrote: >> [snip] Debian uses initramfs-tools... >>> >>> AFAIK, neither genkernel nor dracut were expected to get tied to the >>> Gentoo update process. Has that changed? >> >> The kernel you are running (if you update your machine) is not tied to >> the Gentoo update process. The *source code* gets installed, but the >> kernel source remains unchanged in /usr/src/whatever. It's the user >> responsibility to configure, compile, and install the kernel (and then >> update LILO, grub-legacy or GRUB2). It can be automated with (ta-da) >> genkernel, but it's not "tied to the Gentoo update process". >> >> I really don't see that much difference with needing to also update >> the initramfs, if needed. > > What if your DNS resolver in your rescue shell has a vulnerability? > What if wget, links or whatever network tools you use during recovery > have a vulnerability? > > These are tools which are commonly placed in initramfs. First of all, none of this has nothing to do with the discussion at hand. Second, I don't know what kind of initramfs you are familiar with, but mine has nothing network related, and I don't see *any* reason to include *anything* network related to an initramfs. >> Because, besides, if your /usr is not in a different partition, you >> don't even *need* an initramfs. In that case not using an initramfs is >> supported by all upstreams. > > And what of /var? /opt? What about them? Again, what it has this anything to do with our current discussion? > The problem with the /usr merge upstream is > that someone didn't think things through when they pushed it, and the > same reasoning used to justify it easily justifies changing the way > /var and /opt are treated. That's pure speculation. Nobody has ever suggested merging /opt nor /var; if I'm mistaken I would love to see even a single link (mail, blog post, IRC discussion) were it was at least mentioned as a good idea to do the same with /opt or /var. I'm pretty sure you don't have any. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman wrote: > On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol wrote: >> AFAIK, neither genkernel nor dracut were expected to get tied to the >> Gentoo update process. Has that changed? > > We don't even update kernels as part of the regular update process, > let alone initramfs systems. > > In general you update them together. > > The only issue I could see is if problems arise if you have a > different version of udev in your initramfs than on your system. I > don't know if that actually causes problems. For the most part after > the system is booted the initramfs is done its job. The most widely touted benefit I've heard for initramfs is its capability to ease system recovery in case, e.g. a critical filesystem refuses to mount. With recovery roles come recovery tools, which quickly extends network-aware tools and a security attack surface. Hence why I tend to feel that if an initramfs is going to become the go-to solution for bootstrapping userland, it's important to consider the difficulties of keeping the packed tools up-to-date; it's not just a bootstrap tool, it's also the first recovery option a sysadmin faces. > > If some package did need a kernel/initramfs/etc to be updated it > should be the subject of news or an ewarn unless it becomes routine > practice. I don't think we want the system to start touching these > things without operator intervention unless we make it really > bulletproof like they do on big distros (the only reason they can is > they have one-size-fits-all kernels and initramfs designs). Absolutely. -- :wq
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés wrote: > On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol wrote: >> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner wrote: > [snip] >>> Debian uses initramfs-tools... >> >> AFAIK, neither genkernel nor dracut were expected to get tied to the >> Gentoo update process. Has that changed? > > The kernel you are running (if you update your machine) is not tied to > the Gentoo update process. The *source code* gets installed, but the > kernel source remains unchanged in /usr/src/whatever. It's the user > responsibility to configure, compile, and install the kernel (and then > update LILO, grub-legacy or GRUB2). It can be automated with (ta-da) > genkernel, but it's not "tied to the Gentoo update process". > > I really don't see that much difference with needing to also update > the initramfs, if needed. What if your DNS resolver in your rescue shell has a vulnerability? What if wget, links or whatever network tools you use during recovery have a vulnerability? These are tools which are commonly placed in initramfs. > > Because, besides, if your /usr is not in a different partition, you > don't even *need* an initramfs. In that case not using an initramfs is > supported by all upstreams. And what of /var? /opt? The problem with the /usr merge upstream is that someone didn't think things through when they pushed it, and the same reasoning used to justify it easily justifies changing the way /var and /opt are treated. -- :wq
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol wrote: > AFAIK, neither genkernel nor dracut were expected to get tied to the > Gentoo update process. Has that changed? We don't even update kernels as part of the regular update process, let alone initramfs systems. In general you update them together. The only issue I could see is if problems arise if you have a different version of udev in your initramfs than on your system. I don't know if that actually causes problems. For the most part after the system is booted the initramfs is done its job. If some package did need a kernel/initramfs/etc to be updated it should be the subject of news or an ewarn unless it becomes routine practice. I don't think we want the system to start touching these things without operator intervention unless we make it really bulletproof like they do on big distros (the only reason they can is they have one-size-fits-all kernels and initramfs designs). Rich
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol wrote: > On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner wrote: [snip] >> Debian uses initramfs-tools... > > AFAIK, neither genkernel nor dracut were expected to get tied to the > Gentoo update process. Has that changed? The kernel you are running (if you update your machine) is not tied to the Gentoo update process. The *source code* gets installed, but the kernel source remains unchanged in /usr/src/whatever. It's the user responsibility to configure, compile, and install the kernel (and then update LILO, grub-legacy or GRUB2). It can be automated with (ta-da) genkernel, but it's not "tied to the Gentoo update process". I really don't see that much difference with needing to also update the initramfs, if needed. Because, besides, if your /usr is not in a different partition, you don't even *need* an initramfs. In that case not using an initramfs is supported by all upstreams. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner wrote: > On Wed, Jul 18, 2012 at 8:25 PM, Michael Mol wrote: [snip] >> To me, it looks a lot like what once was / is now expected to be an >> initramfs, which I find extraordinarily problematic, for the following >> reasons: >> >> 1) There are no truly mature tools for automatically generating and >> installing an initramfs based on system requirements. Canek likes to >> recommend dracut, which still isn't marked stable. I've gotten stable >> genkernel to work reasonably, but its error reporting is terrible. >> 2) There's no good means for applying software and security updates to >> an initramfs. If having an initramfs is to be considered the new >> normal, there should be some means of updating it as part of routine >> system updates. > > Debian uses initramfs-tools... AFAIK, neither genkernel nor dracut were expected to get tied to the Gentoo update process. Has that changed? -- :wq
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 8:25 PM, Michael Mol wrote: > On Wed, Jul 18, 2012 at 1:58 PM, Michał Górny wrote: >> On Wed, 18 Jul 2012 18:40:12 +0100 >> Ciaran McCreesh wrote: >> >>> On Wed, 18 Jul 2012 12:35:58 -0500 >>> Canek Peláez Valdés wrote: >>> > All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin >>> > separated are really instances of the Chewbacca defense [1]. They >>> > just don't make any sense. >>> >>> All the arguments for changing things are just realising that the >>> horse has fled the barn and then trying to rationalise not needing a >>> horse. >> >> I believe I don't need a horse. I don't even have a barn either. > > To carry the analogy, udev forcing a /usr merge is much like "We don't > need a horse, so we don't think anyone else should have one, either. > If they need a horse, they can use one of those newfangled tractors." > > Personally, I think the original reasoning behind udev's move was > flawed. When I read it, it sounded like "we can't control whether or > not anyone else puts boot-required packages into /usr before /usr has > been mounted. In order to cover for those packages, we'll force the > issue by putting ourselves there." > > I think that any package which puts boot-required things into a path > which may not be available at boot time is inherently broken, and > needs to be fixed. There's absolutely nothing about the move which > both accounts for boot-required packages requiring access to /var > _and_ a sysadmin's need to have /var as a special mount point. > > To me, it looks a lot like what once was / is now expected to be an > initramfs, which I find extraordinarily problematic, for the following > reasons: > > 1) There are no truly mature tools for automatically generating and > installing an initramfs based on system requirements. Canek likes to > recommend dracut, which still isn't marked stable. I've gotten stable > genkernel to work reasonably, but its error reporting is terrible. > 2) There's no good means for applying software and security updates to > an initramfs. If having an initramfs is to be considered the new > normal, there should be some means of updating it as part of routine > system updates. Debian uses initramfs-tools... > 3) With an initramfs and the tools to generate it, we have more moving > parts were previously there were few. > > -- > :wq >
Re: [gentoo-dev] Opinion against /usr merge
On Wed, 18 Jul 2012 11:35:02 -0400 "Walter Dnes" wrote: > On Tue, Jul 17, 2012 at 07:12:09PM -0500, William Hubbs wrote > > On Tue, Jul 17, 2012 at 07:19:48PM -0400, Richard Yao wrote: > > > > > > Looking at @system and what it typically pulls into @world, the > > > only thing that might cause a problem is udev, although > > > virtual/dev-manager is in @system, rather than udev. If that > > > happens, we have a few ways of dealing with that: > > > > > > 1. Patch udev. > > > > I think I can come up with a patch locally that will read rules from > > /lib/udev/rules.d if that's what we want to do for now. > > > > > 2. Fork udev. > > > > I don't think this is necessary, and it would create more work for > > us than is needed. > > 3. More support for mdev; e.g. https://wiki.gentoo.org/wiki/Mdev > and (still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB > The next challenge is "custom mdev rules", which should be do-able. I don't think we should give more support to building a system from a statically linked rescue suite tool. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 1:58 PM, Michał Górny wrote: > On Wed, 18 Jul 2012 18:40:12 +0100 > Ciaran McCreesh wrote: > >> On Wed, 18 Jul 2012 12:35:58 -0500 >> Canek Peláez Valdés wrote: >> > All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin >> > separated are really instances of the Chewbacca defense [1]. They >> > just don't make any sense. >> >> All the arguments for changing things are just realising that the >> horse has fled the barn and then trying to rationalise not needing a >> horse. > > I believe I don't need a horse. I don't even have a barn either. To carry the analogy, udev forcing a /usr merge is much like "We don't need a horse, so we don't think anyone else should have one, either. If they need a horse, they can use one of those newfangled tractors." Personally, I think the original reasoning behind udev's move was flawed. When I read it, it sounded like "we can't control whether or not anyone else puts boot-required packages into /usr before /usr has been mounted. In order to cover for those packages, we'll force the issue by putting ourselves there." I think that any package which puts boot-required things into a path which may not be available at boot time is inherently broken, and needs to be fixed. There's absolutely nothing about the move which both accounts for boot-required packages requiring access to /var _and_ a sysadmin's need to have /var as a special mount point. To me, it looks a lot like what once was / is now expected to be an initramfs, which I find extraordinarily problematic, for the following reasons: 1) There are no truly mature tools for automatically generating and installing an initramfs based on system requirements. Canek likes to recommend dracut, which still isn't marked stable. I've gotten stable genkernel to work reasonably, but its error reporting is terrible. 2) There's no good means for applying software and security updates to an initramfs. If having an initramfs is to be considered the new normal, there should be some means of updating it as part of routine system updates. 3) With an initramfs and the tools to generate it, we have more moving parts were previously there were few. -- :wq
Re: [gentoo-dev] Opinion against /usr merge
On 18-07-2012 14:11:07 -0400, Michael Mol wrote: > Worse, I think /home to /Users is an *egregiously* poor choice; any > native English speaker who has rudimenatry (or even intimate) > knowledge of how things previously worked would be very likely to > confuse /Users with the historical /usr. You *are* aware OSX uses this, right? > ... Heck, I know a local guy who > has to struggle to get newish versions of Python, CUPS and other > things onto an AIX box, because those are the tools he has to use to > satisfy company needs. Based on IRC conversations, it sounds like he > spends at least 5% of his time (that *I* know about, anyway) trying to > wedge new software into old systems. How is this related to something like a /usr merge? > Ugh. I've gone offtopic. This email went from having anything to do > with udev to being about filesystems layouts. Seems to me we're in a different thread here :) -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 5:35 PM, Walter Dnes wrote: > > 3. More support for mdev; e.g. https://wiki.gentoo.org/wiki/Mdev and > (still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB The > next challenge is "custom mdev rules", which should be do-able. Interesting. Can you talk more about the benefits of mdev in non-embedded systems? Why would I want to use this instead of udev (aside from the /usr dispute).
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 11:04 AM, Canek Peláez Valdés wrote: > I don't mind the merge of /bin, /usr/bin, /sbin and /usr/sbin; > moreover, I want an even more radical change: > > /usr -> /System > /home -> /Users > /etc -> /Config This would be a terrible idea, IMO. If you can rationalize this, why not any of these? /etc -> /設定 /etc -> /组态 /etc -> /組態 /etc -> /configuración Codes (and things like 'usr', 'etc' and 'home' are codes) may not be the most intuitive, but they have roughly the same difficulty regardless of your source language. Worse, I think /home to /Users is an *egregiously* poor choice; any native English speaker who has rudimenatry (or even intimate) knowledge of how things previously worked would be very likely to confuse /Users with the historical /usr. > Why should we care about ancient filesystems that didn't supported > long paths, and therefore we got stuck with /usr since we didn't > wanted to waste another *single* character to make it /user? > > Let that silly legacy stuff die. Keep symbolic links to the old > directories for compatibility reasons, if you want to (modern software > should not need it anyhow), and move on. Remember /usr/X11R6? We kept > a /usr/X11R6 -> /usr link for years. Do you miss it? The longer something exists, the more things like procedures and best practices grow to depend on it both explicitly and implicitly. There's a lot of stuff out there which assumes the existing structure. Stuff that people don't necessarily even think about any more, because it just works. Grossly changing the filesystem layout does worse than make maintenance of known software more difficult, it changes a lot of longstanding assumptions for ancient, still-functional code written ages upon ages ago, and it makes it that much more difficult to install new software onto production systems which have been running for decades. That's the legacy of being a UNIX-alike. Heck, I know a local guy who has to struggle to get newish versions of Python, CUPS and other things onto an AIX box, because those are the tools he has to use to satisfy company needs. Based on IRC conversations, it sounds like he spends at least 5% of his time (that *I* know about, anyway) trying to wedge new software into old systems. Change almost always breaks more things than you expect, because you only expect the things you remembered to consider, not the things you forgot existed. Ugh. I've gone offtopic. This email went from having anything to do with udev to being about filesystems layouts. -- :wq
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 8:35 PM, Canek Peláez Valdés wrote: > But it must be clear that all the rationale behind > said division was invented after the fact, I would say that the rationale was not “invented”, but rather adapted to an evolving system. > and (as Rob Landley said in > his email [2]) maintained "for decades by bureaucrats who never > question _why_ they're doing things". I am surprised that anyone took that rant seriously. It is just a rant, ignoring evolution of systems (where initially arbitrary configuration changes and gets meaning with time), and treating developers who have to deal with backwards compatibility issues and established usage conventions as thick bureaucrats. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Opinion against /usr merge
On Wed, 18 Jul 2012 18:40:12 +0100 Ciaran McCreesh wrote: > On Wed, 18 Jul 2012 12:35:58 -0500 > Canek Peláez Valdés wrote: > > All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin > > separated are really instances of the Chewbacca defense [1]. They > > just don't make any sense. > > All the arguments for changing things are just realising that the > horse has fled the barn and then trying to rationalise not needing a > horse. I believe I don't need a horse. I don't even have a barn either. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 1:07 AM, Olivier Crête wrote: > Also be ready for a merge of /bin and /sbin.. I'm sure most people can't > even explain the difference between them. Whoa hey what why? Who's pushing this forward?
Re: [gentoo-dev] Opinion against /usr merge
On Wed, 18 Jul 2012 12:35:58 -0500 Canek Peláez Valdés wrote: > All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin > separated are really instances of the Chewbacca defense [1]. They just > don't make any sense. All the arguments for changing things are just realising that the horse has fled the barn and then trying to rationalise not needing a horse. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 11:13 AM, Hobbit wrote: >> Why should we care about ancient filesystems that didn't supported >> long paths, and therefore we got stuck with /usr since we didn't >> wanted to waste another *single* character to make it /user? > > Because of it's original name: "UNIX System Resources" (usr). As William pointed out, this is just another silly rationalization done after the fact. But, just for argument's sake, lets suppose that "usr" was named like that because it was the acronym for "UNIX System Resources". *Who cares about that now?* It was 43 years ago. My cellphone is thousands of times faster than the PDP-7 Unix was originally developed for, and it has millions of times more storage. The length restrictions imposed on system directories are completely superfluous now. All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin separated are really instances of the Chewbacca defense [1]. They just don't make any sense. If upstream projects want to move everything to one location, Gentoo should follow suit. If enough Gentoo devs (as others had argued) want to waste their efforts in maintaining this artificial and silly division between /bin, /sbin, /usr/bin, and /usr/sbin, it is of course their prerogative. But it must be clear that all the rationale behind said division was invented after the fact, and (as Rob Landley said in his email [2]) maintained "for decades by bureaucrats who never question _why_ they're doing things". Regards. [1] http://en.wikipedia.org/wiki/Chewbacca_defense [2] http://lists.busybox.net/pipermail/busybox/2010-December/074114.html -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Opinion against /usr merge
On 11:26 Wed 18 Jul , William Hubbs wrote: > Actually this is not correct (see my earlier post with the link to > osnews.com). Indeed. My bad.
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 08:13:51PM +0400, Hobbit wrote: > > Why should we care about ancient filesystems that didn't supported > > long paths, and therefore we got stuck with /usr since we didn't > > wanted to waste another *single* character to make it /user? > > Because of it's original name: "UNIX System Resources" (usr). Actually this is not correct (see my earlier post with the link to osnews.com). Originally it contained user directories like /home does now. William pgpc1JoopQ1kk.pgp Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
> Why should we care about ancient filesystems that didn't supported > long paths, and therefore we got stuck with /usr since we didn't > wanted to waste another *single* character to make it /user? Because of it's original name: "UNIX System Resources" (usr).
Re: [gentoo-dev] Opinion against /usr merge
On Tue, Jul 17, 2012 at 07:12:09PM -0500, William Hubbs wrote > On Tue, Jul 17, 2012 at 07:19:48PM -0400, Richard Yao wrote: > > > > Looking at @system and what it typically pulls into @world, the only > > thing that might cause a problem is udev, although virtual/dev-manager > > is in @system, rather than udev. If that happens, we have a few ways of > > dealing with that: > > > > 1. Patch udev. > > I think I can come up with a patch locally that will read rules from > /lib/udev/rules.d if that's what we want to do for now. > > > 2. Fork udev. > > I don't think this is necessary, and it would create more work for us > than is needed. 3. More support for mdev; e.g. https://wiki.gentoo.org/wiki/Mdev and (still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB The next challenge is "custom mdev rules", which should be do-able. -- Walter Dnes
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 8:18 AM, Richard Yao wrote: > On 07/18/2012 04:10 AM, Michał Górny wrote: >> On Tue, 17 Jul 2012 23:54:16 -0400 >> Richard Yao wrote: [snip] >>> The difference is simple. You put stuff into /sbin when you do not >>> want regular users to be able to select it via tab completion by >>> default. >> >> Now put that definition into my cold logic brain. > > That was meant as a joke, although the irony is that it is true. So, you are rationalizing a posteriori an original irrational decision. Understanding the bin, sbin, usr/bin , usr/sbin split: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html "The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented, for multiple reasons" I don't mind the merge of /bin, /usr/bin, /sbin and /usr/sbin; moreover, I want an even more radical change: /usr -> /System /home -> /Users /etc -> /Config Why should we care about ancient filesystems that didn't supported long paths, and therefore we got stuck with /usr since we didn't wanted to waste another *single* character to make it /user? Let that silly legacy stuff die. Keep symbolic links to the old directories for compatibility reasons, if you want to (modern software should not need it anyhow), and move on. Remember /usr/X11R6? We kept a /usr/X11R6 -> /usr link for years. Do you miss it? I surely not. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Opinion against /usr merge
On 07/18/2012 04:10 AM, Michał Górny wrote: > On Tue, 17 Jul 2012 23:54:16 -0400 > Richard Yao wrote: > >> On 07/17/2012 07:07 PM, Olivier Crête wrote: >>> On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote: If somebody really is pushing for an all-out /usr move by all means speak up, but I think that basically what everybody is advocating is trying to follow upstream for individual packages. >>> >>> As I've been saying for a while, doing a full merge >>> of /bin, /sbin, /lib into /usr is probably unavoidable in the long >>> term. We should be ready for it, and even try to do it >>> progressively. As currently, the split is entirely arbitrary. >>> >>> Also be ready for a merge of /bin and /sbin.. I'm sure most people >>> can't even explain the difference between them. >>> >> >> The difference is simple. You put stuff into /sbin when you do not >> want regular users to be able to select it via tab completion by >> default. > > Now put that definition into my cold logic brain. > That was meant as a joke, although the irony is that it is true. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 17 Jul 2012 17:20:13 -0400 Richard Yao wrote: > Dear Everyone, > > An often cited benefit of the /usr merge is the ability to put > everything but /etc on NFS and for that reason, we need to force an > initramfs on people happily using /usr without it. You forgot about /var. And possibly /srv. But yes, you are probably having separate filesystems so you don't care about people having different layout. > With that said, there is a great deal of FUD being spread by the > systemd developers and I see no reason for us to accept it. We would > be breaking users' systems for no gain other than to make the systemd > developers happy. Their refusal to permit udev to be built separately > from systemd demonstrated complete disdain for Gentoo Linux. Why > should we let them dictate how we design our distribution at our > users' expense? Didn't you see Lennart's opinions on Gentoo Linux? I don't think their refusal needed to be expressed at all. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 17 Jul 2012 23:54:16 -0400 Richard Yao wrote: > On 07/17/2012 07:07 PM, Olivier Crête wrote: > > On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote: > >> If somebody really is pushing for an all-out /usr move by all means > >> speak up, but I think that basically what everybody is advocating > >> is trying to follow upstream for individual packages. > > > > As I've been saying for a while, doing a full merge > > of /bin, /sbin, /lib into /usr is probably unavoidable in the long > > term. We should be ready for it, and even try to do it > > progressively. As currently, the split is entirely arbitrary. > > > > Also be ready for a merge of /bin and /sbin.. I'm sure most people > > can't even explain the difference between them. > > > > The difference is simple. You put stuff into /sbin when you do not > want regular users to be able to select it via tab completion by > default. Now put that definition into my cold logic brain. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 17 Jul 2012 17:20:13 -0400 Richard Yao wrote: > An often cited benefit of the /usr merge is the ability to put > everything but /etc on NFS and for that reason, we need to force an > initramfs on people happily using /usr without it. Are you going to send a single mail for every single benefit I will add to the wiki? :> -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 23:24 -0400, Richard Yao wrote: > GNOME is part of the GNU project, so we should be safe unless they > decide against portability. OpenSuSe and Mageia are other distributions, > so they are not upstream for us. With my GNOME hat on: GNOME does not take any marching orders from RMS or anyone else in the GNU project. We will do any changes that we believe are necessary to produce a better end user experience or to make our code more maintainable. If that means adding dependencies that are Linux specific, we will do it. And we have done it before, for example, we have dependencies on udev for certain features. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 23:54 -0400, Richard Yao wrote: > On 07/17/2012 07:07 PM, Olivier Crête wrote: > > On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote: > >> If somebody really is pushing for an all-out /usr move by all means > >> speak up, but I think that basically what everybody is advocating is > >> trying to follow upstream for individual packages. > > > > As I've been saying for a while, doing a full merge of /bin, /sbin, /lib > > into /usr is probably unavoidable in the long term. We should be ready > > for it, and even try to do it progressively. As currently, the split is > > entirely arbitrary. > > > > Also be ready for a merge of /bin and /sbin.. I'm sure most people can't > > even explain the difference between them. > > > > The difference is simple. You put stuff into /sbin when you do not want > regular users to be able to select it via tab completion by default. That's certainly not how te FHS explains it. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On 07/17/2012 07:07 PM, Olivier Crête wrote: > On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote: >> If somebody really is pushing for an all-out /usr move by all means >> speak up, but I think that basically what everybody is advocating is >> trying to follow upstream for individual packages. > > As I've been saying for a while, doing a full merge of /bin, /sbin, /lib > into /usr is probably unavoidable in the long term. We should be ready > for it, and even try to do it progressively. As currently, the split is > entirely arbitrary. > > Also be ready for a merge of /bin and /sbin.. I'm sure most people can't > even explain the difference between them. > The difference is simple. You put stuff into /sbin when you do not want regular users to be able to select it via tab completion by default. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Opinion against /usr merge
On 07/17/2012 09:28 PM, Jeff Horelick wrote: > On 17 July 2012 21:17, Richard Yao wrote: >> On 07/17/2012 08:46 PM, Rich Freeman wrote: >>> If we don't do anything, then lots of stuff moves to /usr. I think >>> that is what you're missing. The /usr move basically starts happening >>> on its own automatically if we DON'T do much. This is because >>> upstream is the one pushing it. >> >> Which upstream is pushing this? So far, only RedHat wants this and their >> ability to get various upstreams to try to force it is rather limited. >> The only upstream where I have seen any indication that this could be >> forced is systemd. >> > > Forgetting that GNOME is mostly managed by RedHat employees, OpenSuSE > and Mageia tend to follow RedHat's leadI can probably go on if I > cared to do more research. > GNOME is part of the GNU project, so we should be safe unless they decide against portability. OpenSuSe and Mageia are other distributions, so they are not upstream for us. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Opinion against /usr merge
On 17 July 2012 21:17, Richard Yao wrote: > On 07/17/2012 08:46 PM, Rich Freeman wrote: >> If we don't do anything, then lots of stuff moves to /usr. I think >> that is what you're missing. The /usr move basically starts happening >> on its own automatically if we DON'T do much. This is because >> upstream is the one pushing it. > > Which upstream is pushing this? So far, only RedHat wants this and their > ability to get various upstreams to try to force it is rather limited. > The only upstream where I have seen any indication that this could be > forced is systemd. > Forgetting that GNOME is mostly managed by RedHat employees, OpenSuSE and Mageia tend to follow RedHat's leadI can probably go on if I cared to do more research.
Re: [gentoo-dev] Opinion against /usr merge
On 07/17/2012 08:46 PM, Rich Freeman wrote: > If we don't do anything, then lots of stuff moves to /usr. I think > that is what you're missing. The /usr move basically starts happening > on its own automatically if we DON'T do much. This is because > upstream is the one pushing it. Which upstream is pushing this? So far, only RedHat wants this and their ability to get various upstreams to try to force it is rather limited. The only upstream where I have seen any indication that this could be forced is systemd. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Opinion against /usr merge
On Tue, Jul 17, 2012 at 08:37:03PM -0400, Ian Stakenvicius wrote: > > On 2012-07-17, at 7:07 PM, Olivier Crête wrote: > > > I'm sure most people can't > > even explain the difference between them. > > > > /sbin is for bins that only root should be able to run. easy. :) Not quite, check out this link [1]. William [1] http://www.osnews.com/story/25556 pgp6iqD4s1pKe.pgp Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 20:37 -0400, Ian Stakenvicius wrote: > On 2012-07-17, at 7:07 PM, Olivier Crête wrote: > > > I'm sure most people can't > > even explain the difference between them. > > > > /sbin is for bins that only root should be able to run. easy. :) Or you can try this experiment and see what breaks: chmod og-rwx /sbin/* /usr/sbin/* -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 20:37 -0400, Ian Stakenvicius wrote: > On 2012-07-17, at 7:07 PM, Olivier Crête wrote: > > > I'm sure most people can't > > even explain the difference between them. > > > > /sbin is for bins that only root should be able to run. easy. :) Except when it isn't the case, for example /sbin/ifconfig is a good way to find one's ip address, etc. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, Jul 17, 2012 at 8:34 PM, Richard Yao wrote: > I have yet to see any convincing reason to do this other than "RedHat is > doing it". This change will not make Gentoo a better distribution and it > is simply not worth the pain. Some people appear to think that this is > an urgent issue and I doubt anything I say will change their minds. The > main problem that I have is getting them to accept that they are wrong > that urgent action is needed. I firmly believe that we could wait a few > years before doing anything. I don't think anybody else is suggesting doing anything at all in the first place. If we don't do anything, then lots of stuff moves to /usr. I think that is what you're missing. The /usr move basically starts happening on its own automatically if we DON'T do much. This is because upstream is the one pushing it. Few are advocating rushing either - if upstream takes years to make this happen I doubt it will upset many on this list. My sense is the general maintainer sentiment is to go with the flow - they're not going to patch udev/etc to move more stuff into usr, but they're not gong to patch it to move stuff back out either. If you really want to support leaving stuff where it is then you or others need to volunteer to start helping with maintaining these packages, and deal with any mess it creates. Rich
Re: [gentoo-dev] Opinion against /usr merge
On 07/17/2012 08:12 PM, William Hubbs wrote: Lastly, don't tell me to read systemd's case for why we should break people's systems. I have read it and I find it flawed. There is absolutely no need for us to make this change. >>> >>> Without elaboration on why you find their case flawed, this sounds >>> like the typical, "if it isn't broke, don't fix it" argument. >>> While that has merrit, if there are advantages to doing >>> something, like I think there would be to doing the /usr merge, it may >>> be worth the transition, especially if we can make it as smooth as >>> possible. >> >> The cost to benefit ratio is simply too low for "lets change it because >> it could be better this way" to merit making the change. The things that >> I have heard are going to break existing systems that I have gone >> through some trouble to support. I really don't want to see that. > > You are still not saying what things you have heard. Your concerns can't > be addressed if you don't tell us what they are. > > William > I have yet to see any convincing reason to do this other than "RedHat is doing it". This change will not make Gentoo a better distribution and it is simply not worth the pain. Some people appear to think that this is an urgent issue and I doubt anything I say will change their minds. The main problem that I have is getting them to accept that they are wrong that urgent action is needed. I firmly believe that we could wait a few years before doing anything. With that said, I have done enough to get the attention of systemd advocates. Giving you an itemized critique of the systemd documentation on the list would draw even more attention to myself and I do not want that. Anything more needs to be said off the list, but quite frankly, I think what I have said is more than sufficient. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Opinion against /usr merge
On 2012-07-17, at 7:07 PM, Olivier Crête wrote: > I'm sure most people can't > even explain the difference between them. > /sbin is for bins that only root should be able to run. easy. :)
Re: [gentoo-dev] Opinion against /usr merge
On Tue, Jul 17, 2012 at 07:19:48PM -0400, Richard Yao wrote: > On 07/17/2012 07:02 PM, William Hubbs wrote: > > This is basically not relevant since we do not support HURD. > > It is relevant because it guarantees that the GNU stuff in @system will > continue working. That allows us to narrow our focus to the non-GNU > things required to use Gentoo Linux. > > Looking at @system and what it typically pulls into @world, the only > thing that might cause a problem is udev, although virtual/dev-manager > is in @system, rather than udev. If that happens, we have a few ways of > dealing with that: > > 1. Patch udev. I think I can come up with a patch locally that will read rules from /lib/udev/rules.d if that's what we want to do for now. > 2. Fork udev. I don't think this is necessary, and it would create more work for us than is needed. > >> Lastly, don't tell me to read systemd's case for why we should break > >> people's systems. I have read it and I find it flawed. There is > >> absolutely no need for us to make this change. > > > > Without elaboration on why you find their case flawed, this sounds > > like the typical, "if it isn't broke, don't fix it" argument. > > While that has merrit, if there are advantages to doing > > something, like I think there would be to doing the /usr merge, it may > > be worth the transition, especially if we can make it as smooth as > > possible. > > The cost to benefit ratio is simply too low for "lets change it because > it could be better this way" to merit making the change. The things that > I have heard are going to break existing systems that I have gone > through some trouble to support. I really don't want to see that. You are still not saying what things you have heard. Your concerns can't be addressed if you don't tell us what they are. William pgpM4wdMCDc6P.pgp Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
William Hubbs wrote: > On Tue, Jul 17, 2012 at 06:13:06PM -0500, Dale wrote: >> William Hubbs wrote: >>> >>> This is not quite correct. The initramfs is required because of [1]. >>> >>> >>> William >>> >> Where is [1]? > [1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > > We have a way around this in some limited circumstances with > busybox[sep-usr], but that definitely does not support anything fancy > like rade, lvm, etc. > > William > Ah, read that link a while back. Nothing new there I don't guess. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Opinion against /usr merge
On Tue, Jul 17, 2012 at 06:13:06PM -0500, Dale wrote: > > William Hubbs wrote: > > > > This is not quite correct. The initramfs is required because of [1]. > > > > > > William > > > > Where is [1]? [1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken We have a way around this in some limited circumstances with busybox[sep-usr], but that definitely does not support anything fancy like rade, lvm, etc. William pgpwvudC8KtOA.pgp Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
On 07/17/2012 07:02 PM, William Hubbs wrote: > On Tue, Jul 17, 2012 at 05:20:13PM -0400, Richard Yao wrote: >> An often cited benefit of the /usr merge is the ability to put >> everything but /etc on NFS and for that reason, we need to force an >> initramfs on people happily using /usr without it. > > This is not quite correct. The initramfs is required because of [1]. What is [1]? >> Interestingly, the /usr merge changes made to genkernel permit us to >> mount /etc from a genkernel-built initramfs by putting /etc on a >> separate mount point in fstab and then doing `echo /etc >> >> /etc/initramfs.mounts`. > > That doesn't negate putting /usr on nfs and making it possible for > different hosts to share it. People can still have different hosts share / with host-specific stuff (e.g. /etc) mounted by genkernel. >> I have also been told that the /usr merge is necessary because upstream >> will force it on us. Interestingly, most of @system on Gentoo Linux is >> GNU software, which would need to stop supporting things in / in order >> for that to happen. As far ass I know, systemd does not work on GNU HURD >> and it would be incapable of functioning if the GNU project made this >> change. Hell will freeze long before that happens. > > This is basically not relevant since we do not support HURD. It is relevant because it guarantees that the GNU stuff in @system will continue working. That allows us to narrow our focus to the non-GNU things required to use Gentoo Linux. Looking at @system and what it typically pulls into @world, the only thing that might cause a problem is udev, although virtual/dev-manager is in @system, rather than udev. If that happens, we have a few ways of dealing with that: 1. Patch udev. 2. Fork udev. 3. Consider breaking people's systems then. Until then, doing what RedHat wants is unnecessary. >> Lastly, don't tell me to read systemd's case for why we should break >> people's systems. I have read it and I find it flawed. There is >> absolutely no need for us to make this change. > > Without elaboration on why you find their case flawed, this sounds > like the typical, "if it isn't broke, don't fix it" argument. > While that has merrit, if there are advantages to doing > something, like I think there would be to doing the /usr merge, it may > be worth the transition, especially if we can make it as smooth as > possible. The cost to benefit ratio is simply too low for "lets change it because it could be better this way" to merit making the change. The things that I have heard are going to break existing systems that I have gone through some trouble to support. I really don't want to see that. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Opinion against /usr merge
On Tue, Jul 17, 2012 at 06:41:26PM -0400, Rich Freeman wrote: > In any case, it sounds like for now some devs are continuing to adjust > ebuilds to keep a separate /usr working as well as possible, though it > apparently breaks in some edge cases right now without an initramfs, > as you've already noted in your email. > > I don't think anybody in Gentoo is really pushing for a /usr merge - > there are just lots of devs saying that they aren't going to spend a > lot of time stopping it either. If upstream sticks files needed to > boot in /usr then it is basically up to somebody who cares to do > something to move them. Right now that isn't a lot of work, but the > reason people are concerned is that this is likely to change. Right, I'm definitely not advocating a full out /usr merge tomorrow or anything, I am just not interested in doing a whole lot of patching to keep something from moving to /usr if upstream moves it there. Also, I am interested in looking at what is installed in /, and if upstream defaults put it in /usr, allowing it to happen on gentoo that way as well. My thought is that eventually we will have more and more things that are being installed in /usr. > If somebody really is pushing for an all-out /usr move by all means > speak up, but I think that basically what everybody is advocating is > trying to follow upstream for individual packages. Right, that's the issue. Some upstreams (mainly udev) have dropped backward compatibility. But, I will be able to get around those for a while. William pgpR2Wy1yPTyS.pgp Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
William Hubbs wrote: > > This is not quite correct. The initramfs is required because of [1]. > > > William > Where is [1]? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote: > If somebody really is pushing for an all-out /usr move by all means > speak up, but I think that basically what everybody is advocating is > trying to follow upstream for individual packages. As I've been saying for a while, doing a full merge of /bin, /sbin, /lib into /usr is probably unavoidable in the long term. We should be ready for it, and even try to do it progressively. As currently, the split is entirely arbitrary. Also be ready for a merge of /bin and /sbin.. I'm sure most people can't even explain the difference between them. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, Jul 17, 2012 at 05:20:13PM -0400, Richard Yao wrote: > An often cited benefit of the /usr merge is the ability to put > everything but /etc on NFS and for that reason, we need to force an > initramfs on people happily using /usr without it. This is not quite correct. The initramfs is required because of [1]. > Interestingly, the /usr merge changes made to genkernel permit us to > mount /etc from a genkernel-built initramfs by putting /etc on a > separate mount point in fstab and then doing `echo /etc >> > /etc/initramfs.mounts`. That doesn't negate putting /usr on nfs and making it possible for different hosts to share it. > Some people claim that the current approach is somehow broken by citing > Bluetooth keyboards. However, what makes that work is adopting an > initramfs and that does *not* require moving files into /usr. If people > do not want an initramfs, they can simply not have a separate /usr. The > /usr merge gives nothing to people using bluetooth while the /usr merge > will break systems of non-bluetooth users. I don't see what bluetooth has to do with anything other than with the 'separate usr is broken' document which is a separate issue. > I have been told that moving everything into /usr would be easy for us > because Arch Linux did it and they are a rolling distribution too. Arch > Linux does all-or-nothing upgrades. They do not offer the ability for > their users to choose to use older versions of software and we will not > be able to move everything into /usr without breaking existing systems > that boot without issues now. This issue is not completely flushed out with the upstream folks for udev yet, and either way, it will be addressed in our version of udev. > I have also been told that the /usr merge is necessary because upstream > will force it on us. Interestingly, most of @system on Gentoo Linux is > GNU software, which would need to stop supporting things in / in order > for that to happen. As far ass I know, systemd does not work on GNU HURD > and it would be incapable of functioning if the GNU project made this > change. Hell will freeze long before that happens. This is basically not relevant since we do not support HURD. > The only thing that might require a merge is systemd and it is not in > @system. If we offered users the ability to choose rc systems, we would > still be supporting baselayout-1's rc system. If we start now, we should > bring that back. We offer several rc systems in the tree, but I don't know how up to date they are. Either way, bringing back bl1 is not a relevant argument, because it is not compatible with OpenRC. > With that said, there is a great deal of FUD being spread by the systemd > developers and I see no reason for us to accept it. We would be breaking > users' systems for no gain other than to make the systemd developers > happy. Their refusal to permit udev to be built separately from systemd > demonstrated complete disdain for Gentoo Linux. Why should we let them > dictate how we design our distribution at our users' expense? I think we can do the /usr merge in a way that won't break systems; I am looking into that possibility. I am not interested in breaking systems. > Lastly, don't tell me to read systemd's case for why we should break > people's systems. I have read it and I find it flawed. There is > absolutely no need for us to make this change. Without elaboration on why you find their case flawed, this sounds like the typical, "if it isn't broke, don't fix it" argument. While that has merrit, if there are advantages to doing something, like I think there would be to doing the /usr merge, it may be worth the transition, especially if we can make it as smooth as possible. William pgp7n4NWLAhxJ.pgp Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
On Tue, Jul 17, 2012 at 5:20 PM, Richard Yao wrote: > I have also been told that the /usr merge is necessary because upstream > will force it on us. Interestingly, most of @system on Gentoo Linux is > GNU software, which would need to stop supporting things in / in order > for that to happen. I don't think anybody in Gentoo is advocating a full /usr merge. I think that the only thing that has been happening is that there will not be any heroic measures to keep a system with a separate /usr booting without the use of an initramfs or some early-running script. It doesn't matter that the majority of @system software is GNU. For a separate /usr to not work does not require ALL of the software to not support it, but only for a few pieces of software to not support it - a chain is as strong as its weakest link. In any case, it sounds like for now some devs are continuing to adjust ebuilds to keep a separate /usr working as well as possible, though it apparently breaks in some edge cases right now without an initramfs, as you've already noted in your email. I don't think anybody in Gentoo is really pushing for a /usr merge - there are just lots of devs saying that they aren't going to spend a lot of time stopping it either. If upstream sticks files needed to boot in /usr then it is basically up to somebody who cares to do something to move them. Right now that isn't a lot of work, but the reason people are concerned is that this is likely to change. If somebody really is pushing for an all-out /usr move by all means speak up, but I think that basically what everybody is advocating is trying to follow upstream for individual packages. Rich
[gentoo-dev] Opinion against /usr merge
Dear Everyone, An often cited benefit of the /usr merge is the ability to put everything but /etc on NFS and for that reason, we need to force an initramfs on people happily using /usr without it. Interestingly, the /usr merge changes made to genkernel permit us to mount /etc from a genkernel-built initramfs by putting /etc on a separate mount point in fstab and then doing `echo /etc >> /etc/initramfs.mounts`. Some people claim that the current approach is somehow broken by citing Bluetooth keyboards. However, what makes that work is adopting an initramfs and that does *not* require moving files into /usr. If people do not want an initramfs, they can simply not have a separate /usr. The /usr merge gives nothing to people using bluetooth while the /usr merge will break systems of non-bluetooth users. I have been told that moving everything into /usr would be easy for us because Arch Linux did it and they are a rolling distribution too. Arch Linux does all-or-nothing upgrades. They do not offer the ability for their users to choose to use older versions of software and we will not be able to move everything into /usr without breaking existing systems that boot without issues now. I have also been told that the /usr merge is necessary because upstream will force it on us. Interestingly, most of @system on Gentoo Linux is GNU software, which would need to stop supporting things in / in order for that to happen. As far ass I know, systemd does not work on GNU HURD and it would be incapable of functioning if the GNU project made this change. Hell will freeze long before that happens. The only thing that might require a merge is systemd and it is not in @system. If we offered users the ability to choose rc systems, we would still be supporting baselayout-1's rc system. If we start now, we should bring that back. With that said, there is a great deal of FUD being spread by the systemd developers and I see no reason for us to accept it. We would be breaking users' systems for no gain other than to make the systemd developers happy. Their refusal to permit udev to be built separately from systemd demonstrated complete disdain for Gentoo Linux. Why should we let them dictate how we design our distribution at our users' expense? Lastly, don't tell me to read systemd's case for why we should break people's systems. I have read it and I find it flawed. There is absolutely no need for us to make this change. Yours truly, Richard Yao signature.asc Description: OpenPGP digital signature
