Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: On Wed, 18 Jan 2012 01:20:03 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 17 Jan 2012 21:38:26 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: 80 KiB is enough for mounting plain /usr and booting with it. See tiny-initramfs (but I haven't tested it thoroughly). My plan is to have /usr on lvm. I think it will end up larger and it still adds one more thing to break. I really wish someone would get a better plan. I think I see a garbage dump ahead with lots of Linux distros headed that way. Better plan how? LVM requires udev for some reason. Letting rootfs grow with data unnecessary for a number of users is no good plan either. Just install that initramfs, be done with it and let us focus on actual work rather than fixing random breakages. We already usually have separate /boot to satisfy the needs of bootloader. Then you want us to chain yet another filesystem to satisfy the needs of another layer. Initramfs reuses /boot for that. The point is, I don't like initramfs. I don't want to use one. It's funny how I never needed one before either but now things are being broken. It's not LVM that is breaking it either. I wouldn't need the initramfs even if It was on a regular partition until the recent so called improvements. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sat, 21 Jan 2012 06:28:54 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Wed, 18 Jan 2012 01:20:03 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 17 Jan 2012 21:38:26 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: 80 KiB is enough for mounting plain /usr and booting with it. See tiny-initramfs (but I haven't tested it thoroughly). My plan is to have /usr on lvm. I think it will end up larger and it still adds one more thing to break. I really wish someone would get a better plan. I think I see a garbage dump ahead with lots of Linux distros headed that way. Better plan how? LVM requires udev for some reason. Letting rootfs grow with data unnecessary for a number of users is no good plan either. Just install that initramfs, be done with it and let us focus on actual work rather than fixing random breakages. We already usually have separate /boot to satisfy the needs of bootloader. Then you want us to chain yet another filesystem to satisfy the needs of another layer. Initramfs reuses /boot for that. The point is, I don't like initramfs. I don't want to use one. And I don't like binaries on rootfs. I don't want to have ones. So we're talking about taste... It's funny how I never needed one before either but now things are being broken. It's not LVM that is breaking it either. I wouldn't need the initramfs even if It was on a regular partition until the recent so called improvements. ...and your main argument is 'long, long ago someone decided that it should match the same taste as mine, so it should be like it forever'. Of course, those times there were no such thing as an initramfs... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: On Sat, 21 Jan 2012 06:28:54 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Wed, 18 Jan 2012 01:20:03 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 17 Jan 2012 21:38:26 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: 80 KiB is enough for mounting plain /usr and booting with it. See tiny-initramfs (but I haven't tested it thoroughly). My plan is to have /usr on lvm. I think it will end up larger and it still adds one more thing to break. I really wish someone would get a better plan. I think I see a garbage dump ahead with lots of Linux distros headed that way. Better plan how? LVM requires udev for some reason. Letting rootfs grow with data unnecessary for a number of users is no good plan either. Just install that initramfs, be done with it and let us focus on actual work rather than fixing random breakages. We already usually have separate /boot to satisfy the needs of bootloader. Then you want us to chain yet another filesystem to satisfy the needs of another layer. Initramfs reuses /boot for that. The point is, I don't like initramfs. I don't want to use one. And I don't like binaries on rootfs. I don't want to have ones. So we're talking about taste... Actually, we're talking about how things has worked so well for a VERY long time and there is no need to reinvent the wheel. It's funny how I never needed one before either but now things are being broken. It's not LVM that is breaking it either. I wouldn't need the initramfs even if It was on a regular partition until the recent so called improvements. ...and your main argument is 'long, long ago someone decided that it should match the same taste as mine, so it should be like it forever'. Of course, those times there were no such thing as an initramfs... Then don't break that. Just because someone came up with a initramfs doesn't mean everyone should be forced to use one. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 01/21/2012 01:34 PM, Dale wrote: Michał Górny wrote: It's funny how I never needed one before either but now things are being broken. It's not LVM that is breaking it either. I wouldn't need the initramfs even if It was on a regular partition until the recent so called improvements. ...and your main argument is 'long, long ago someone decided that it should match the same taste as mine, so it should be like it forever'. Of course, those times there were no such thing as an initramfs... Then don't break that. Just because someone came up with a initramfs doesn't mean everyone should be forced to use one. The old way imposes requirements that are no longer supported by upstream software. So, you basically have three choices: 1) Use old software that supports the old way 2) Develop new software to support the old way 3) Use an initramfs or pre-init script to mount /usr if it must be on a separate partition -- Thanks, Zac
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sat, 21 Jan 2012 15:34:39 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Sat, 21 Jan 2012 06:28:54 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Wed, 18 Jan 2012 01:20:03 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 17 Jan 2012 21:38:26 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: 80 KiB is enough for mounting plain /usr and booting with it. See tiny-initramfs (but I haven't tested it thoroughly). My plan is to have /usr on lvm. I think it will end up larger and it still adds one more thing to break. I really wish someone would get a better plan. I think I see a garbage dump ahead with lots of Linux distros headed that way. Better plan how? LVM requires udev for some reason. Letting rootfs grow with data unnecessary for a number of users is no good plan either. Just install that initramfs, be done with it and let us focus on actual work rather than fixing random breakages. We already usually have separate /boot to satisfy the needs of bootloader. Then you want us to chain yet another filesystem to satisfy the needs of another layer. Initramfs reuses /boot for that. The point is, I don't like initramfs. I don't want to use one. And I don't like binaries on rootfs. I don't want to have ones. So we're talking about taste... Actually, we're talking about how things has worked so well for a VERY long time and there is no need to reinvent the wheel. And required a considerable amount of work which increases due to software getting more complex and users wanting more features. And I don't get 'the wheel' here? What wheel? I'd say we rather want to get rid of the useless fifth wheel. It's funny how I never needed one before either but now things are being broken. It's not LVM that is breaking it either. I wouldn't need the initramfs even if It was on a regular partition until the recent so called improvements. ...and your main argument is 'long, long ago someone decided that it should match the same taste as mine, so it should be like it forever'. Of course, those times there were no such thing as an initramfs... Then don't break that. Just because someone came up with a initramfs doesn't mean everyone should be forced to use one. And noone is forced to update the system either. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: On Sat, 21 Jan 2012 15:34:39 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Sat, 21 Jan 2012 06:28:54 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Wed, 18 Jan 2012 01:20:03 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 17 Jan 2012 21:38:26 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: 80 KiB is enough for mounting plain /usr and booting with it. See tiny-initramfs (but I haven't tested it thoroughly). My plan is to have /usr on lvm. I think it will end up larger and it still adds one more thing to break. I really wish someone would get a better plan. I think I see a garbage dump ahead with lots of Linux distros headed that way. Better plan how? LVM requires udev for some reason. Letting rootfs grow with data unnecessary for a number of users is no good plan either. Just install that initramfs, be done with it and let us focus on actual work rather than fixing random breakages. We already usually have separate /boot to satisfy the needs of bootloader. Then you want us to chain yet another filesystem to satisfy the needs of another layer. Initramfs reuses /boot for that. The point is, I don't like initramfs. I don't want to use one. And I don't like binaries on rootfs. I don't want to have ones. So we're talking about taste... Actually, we're talking about how things has worked so well for a VERY long time and there is no need to reinvent the wheel. And required a considerable amount of work which increases due to software getting more complex and users wanting more features. And I don't get 'the wheel' here? What wheel? I'd say we rather want to get rid of the useless fifth wheel. Actually, they are adding the fifth wheel. It's funny how I never needed one before either but now things are being broken. It's not LVM that is breaking it either. I wouldn't need the initramfs even if It was on a regular partition until the recent so called improvements. ...and your main argument is 'long, long ago someone decided that it should match the same taste as mine, so it should be like it forever'. Of course, those times there were no such thing as an initramfs... Then don't break that. Just because someone came up with a initramfs doesn't mean everyone should be forced to use one. And noone is forced to update the system either. Oh, that makes perfect sense. Thinks for the showing of brilliance there. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Zac Medico wrote: On 01/21/2012 01:34 PM, Dale wrote: Michał Górny wrote: It's funny how I never needed one before either but now things are being broken. It's not LVM that is breaking it either. I wouldn't need the initramfs even if It was on a regular partition until the recent so called improvements. ...and your main argument is 'long, long ago someone decided that it should match the same taste as mine, so it should be like it forever'. Of course, those times there were no such thing as an initramfs... Then don't break that. Just because someone came up with a initramfs doesn't mean everyone should be forced to use one. The old way imposes requirements that are no longer supported by upstream software. So, you basically have three choices: 1) Use old software that supports the old way 2) Develop new software to support the old way 3) Use an initramfs or pre-init script to mount /usr if it must be on a separate partition So the solution is to break things because things are broken. Sort of running in circles there. Pardon me, I'm dizzy. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 01/21/2012 03:45 PM, Dale wrote: Zac Medico wrote: On 01/21/2012 01:34 PM, Dale wrote: Michał Górny wrote: It's funny how I never needed one before either but now things are being broken. It's not LVM that is breaking it either. I wouldn't need the initramfs even if It was on a regular partition until the recent so called improvements. ...and your main argument is 'long, long ago someone decided that it should match the same taste as mine, so it should be like it forever'. Of course, those times there were no such thing as an initramfs... Then don't break that. Just because someone came up with a initramfs doesn't mean everyone should be forced to use one. The old way imposes requirements that are no longer supported by upstream software. So, you basically have three choices: 1) Use old software that supports the old way 2) Develop new software to support the old way 3) Use an initramfs or pre-init script to mount /usr if it must be on a separate partition So the solution is to break things because things are broken. Well, option 2 means that people have to step up write software that supports the old way. For most people, option 3 is probably the most practical route. -- Thanks, Zac
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 18 Jan 2012 01:20:03 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 17 Jan 2012 21:38:26 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: 80 KiB is enough for mounting plain /usr and booting with it. See tiny-initramfs (but I haven't tested it thoroughly). My plan is to have /usr on lvm. I think it will end up larger and it still adds one more thing to break. I really wish someone would get a better plan. I think I see a garbage dump ahead with lots of Linux distros headed that way. Better plan how? LVM requires udev for some reason. Letting rootfs grow with data unnecessary for a number of users is no good plan either. Just install that initramfs, be done with it and let us focus on actual work rather than fixing random breakages. We already usually have separate /boot to satisfy the needs of bootloader. Then you want us to chain yet another filesystem to satisfy the needs of another layer. Initramfs reuses /boot for that. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: root@fireball / # ls -al /boot/initramfs-3.* -rw-r--r-- 1 root root 5444240 Jan 1 07:24 /boot/initramfs-3.1.5-gentoo.img -rw-r--r-- 1 root root 5515132 Jan 9 07:57 /boot/initramfs-3.2.0-r1.img root@fireball / # That's using the dracut tool. Somehow, over 50Mbs is not anywhere close to 80Kbs, or maybe my calculator is broken. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, Jan 17, 2012 at 10:38 PM, Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: root@fireball / # ls -al /boot/initramfs-3.* -rw-r--r-- 1 root root 5444240 Jan 1 07:24 /boot/initramfs-3.1.5-gentoo.img -rw-r--r-- 1 root root 5515132 Jan 9 07:57 /boot/initramfs-3.2.0-r1.img root@fireball / # That's using the dracut tool. Somehow, over 50Mbs is not anywhere close to 80Kbs, or maybe my calculator is broken. Your calculator is off by a power of 10.
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Mike Gilbert wrote: On Tue, Jan 17, 2012 at 10:38 PM, Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.dewrote: * Micha?? Górnymgo...@gentoo.orgschrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: root@fireball / # ls -al /boot/initramfs-3.* -rw-r--r-- 1 root root 5444240 Jan 1 07:24 /boot/initramfs-3.1.5-gentoo.img -rw-r--r-- 1 root root 5515132 Jan 9 07:57 /boot/initramfs-3.2.0-r1.img root@fireball / # That's using the dracut tool. Somehow, over 50Mbs is not anywhere close to 80Kbs, or maybe my calculator is broken. Your calculator is off by a power of 10. It is. Still, 5Mbs is a lot larger than 80Kbs. Thanks for the correction. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 17 Jan 2012 21:38:26 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: 80 KiB is enough for mounting plain /usr and booting with it. See tiny-initramfs (but I haven't tested it thoroughly). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: On Tue, 17 Jan 2012 21:38:26 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: 80 KiB is enough for mounting plain /usr and booting with it. See tiny-initramfs (but I haven't tested it thoroughly). My plan is to have /usr on lvm. I think it will end up larger and it still adds one more thing to break. I really wish someone would get a better plan. I think I see a garbage dump ahead with lots of Linux distros headed that way. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, 6 Jan 2012 20:05:47 +0100 Michał Górny mgo...@gentoo.org wrote: [snip] You should consider taking like 1 or 2 hours of your precious time to read about the use and meaning of various directories in the filesystem. The FHS gives different meaning to directories than the systemd folks like it to be. Yes, it's unpleasant how far that sort of breakage already progressed. However, by definition software not adhering to the current standard is what is broken and not the other way around. There is nothing wrong with changing an old standard if there is a need, though until a new standard is approved / accepted there is no ground to change anything and breaking the current standard on purpose is plain stupid. Btw, do you happen to know what is going on with FHS-3.0 and why there are delays. Wasn't it supposed to be announced in summer 2011? Then do you happen to know a technical paper which actually discuss the advantage / disadvantages of changing the current standard. All I have read on this topic so far looks like propaganda material only or lists non arguments like less top level directories. signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, Jan 12, 2012 at 7:29 AM, Ralph Sennhauser s...@gentoo.org wrote: On Fri, 6 Jan 2012 20:05:47 +0100 Michał Górny mgo...@gentoo.org wrote: [snip] You should consider taking like 1 or 2 hours of your precious time to read about the use and meaning of various directories in the filesystem. The FHS gives different meaning to directories than the systemd folks like it to be. Yes, it's unpleasant how far that sort of breakage already progressed. However, by definition software not adhering to the current standard is what is broken and not the other way around. We have never aimed to be FHS compliant, so citing the standard is not likely to persuade some. We follow them where we think they make sense and ignore the parts we think are stupid. Just like PMS :) -A There is nothing wrong with changing an old standard if there is a need, though until a new standard is approved / accepted there is no ground to change anything and breaking the current standard on purpose is plain stupid. Btw, do you happen to know what is going on with FHS-3.0 and why there are delays. Wasn't it supposed to be announced in summer 2011? Then do you happen to know a technical paper which actually discuss the advantage / disadvantages of changing the current standard. All I have read on this topic so far looks like propaganda material only or lists non arguments like less top level directories.
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 11 Jan 2012 08:41:04 +0100 Michał Górny mgo...@gentoo.org wrote: Remind me of a single good reason. Last time I heard those were mostly hacks and laziness. Here's one: ability to share disk space automatically between /usr and /home (implication: must be same filesystem; useful because these are the two largest filesystems in most of my installs; substitute /var if you prefer for servers), ability to take consistent backups without stopping activity (implication: /home must be on LVM for snapshots; implication: /usr must also be on LVM due to sharing filesystem with /home), ability to not use an initramfs (implication: root must not be on LVM). Unless you'd like to suggest a better way to achieve all three of these goals? Chris signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 11 Jan 2012, Michał Górny wrote: I think it is more like people do that when they have a good reason to do so. I plan to put mine on /usr when I get the chance and know that this init crap isn't going to break my rig. It's not being awesome either. Remind me of a single good reason. Last time I heard those were mostly hacks and laziness. /usr can be mounted readonly, while / and /var cannot? Ulrich
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 11 Jan 2012 10:34:34 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 16:40:01 -0600 Dalerdalek1...@gmail.com wrote: I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. The mess was created by people shouting 'hey, real men use separate /usr for no good reason! Be awesome like us'. I think it is more like people do that when they have a good reason to do so. I plan to put mine on /usr when I get the chance and know that this init crap isn't going to break my rig. It's not being awesome either. Remind me of a single good reason. Last time I heard those were mostly hacks and laziness. I already stated the reason. I'm going to put /usr on LVM. That is not only a good reason, it is a GREAT reason. It is a hack. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 11 Jan 2012 09:44:31 +0100 Ulrich Mueller u...@gentoo.org wrote: On Wed, 11 Jan 2012, Michał Górny wrote: I think it is more like people do that when they have a good reason to do so. I plan to put mine on /usr when I get the chance and know that this init crap isn't going to break my rig. It's not being awesome either. Remind me of a single good reason. Last time I heard those were mostly hacks and laziness. /usr can be mounted readonly, while / and /var cannot? What is the point of mounting the less important part of the system read-only while the more important one is writable? Also, it should be possible to mount rootfs read-only with separate /var. Of course, that would require the software to be actually FHS-compliant and not put runtime-written files in /etc. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 11 Jan 2012 18:03:50 +0100 Michał Górny mgo...@gentoo.org wrote: On Wed, 11 Jan 2012 09:44:31 +0100 Ulrich Mueller u...@gentoo.org wrote: On Wed, 11 Jan 2012, Michał Górny wrote: I think it is more like people do that when they have a good reason to do so. I plan to put mine on /usr when I get the chance and know that this init crap isn't going to break my rig. It's not being awesome either. Remind me of a single good reason. Last time I heard those were mostly hacks and laziness. /usr can be mounted readonly, while / and /var cannot? What is the point of mounting the less important part of the system read-only while the more important one is writable? Also, it should be possible to mount rootfs read-only with separate /var. Of course, that would require the software to be actually FHS-compliant and not put runtime-written files in /etc. security? -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: On Wed, 11 Jan 2012 10:34:34 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 16:40:01 -0600 Dalerdalek1...@gmail.com wrote: I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. The mess was created by people shouting 'hey, real men use separate /usr for no good reason! Be awesome like us'. I think it is more like people do that when they have a good reason to do so. I plan to put mine on /usr when I get the chance and know that this init crap isn't going to break my rig. It's not being awesome either. Remind me of a single good reason. Last time I heard those were mostly hacks and laziness. I already stated the reason. I'm going to put /usr on LVM. That is not only a good reason, it is a GREAT reason. It is a hack. How is putting /usr, /var, /home and such on LVM a hack? Your definition of hack must have some really low standards. Does installing Linux fall into your hack category to? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 11, 2012 at 10:31 PM, Michał Górny mgo...@gentoo.org wrote: On Wed, 11 Jan 2012 10:34:34 -0600 Dale rdalek1...@gmail.com wrote: I already stated the reason. I'm going to put /usr on LVM. That is not only a good reason, it is a GREAT reason. It is a hack. https://fedoraproject.org/wiki/Features/UsrMove#Benefit_to_Fedora -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 11, 2012 at 9:01 AM, Michał Górny mgo...@gentoo.org wrote: On Wed, 11 Jan 2012 10:34:34 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 16:40:01 -0600 Dalerdalek1...@gmail.com wrote: I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. The mess was created by people shouting 'hey, real men use separate /usr for no good reason! Be awesome like us'. I think it is more like people do that when they have a good reason to do so. I plan to put mine on /usr when I get the chance and know that this init crap isn't going to break my rig. It's not being awesome either. Remind me of a single good reason. Last time I heard those were mostly hacks and laziness. I already stated the reason. I'm going to put /usr on LVM. That is not only a good reason, it is a GREAT reason. It is a hack. Your opinion is noted, but that doesn't make better or worse than other folks ideas. -A -- Best regards, Michał Górny
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Alec Warner wrote: On Wed, Jan 11, 2012 at 9:01 AM, Michał Górnymgo...@gentoo.org wrote: It is a hack. Your opinion is noted, but that doesn't make better or worse than other folks ideas. -A -- Best regards, Michał Górny I agree. It doesn't break things that was working either. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
* Micha?? Górny mgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigelt weig...@metux.de wrote: * Micha?? Górny mgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? Took me days to get dracut to work. Where does 15 minutes come from? How much time does it take when the initramfs fails? I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 10 Jan 2012 12:56:11 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? Took me days to get dracut to work. Where does 15 minutes come from? I just took the time I needed to write an initramfs from scratch and divided it by two, assuming using an already-made tool is simpler. How much time does it take when the initramfs fails? The same when rootfs fails? Only the fact that initramfs is less likely to break than rootfs, and you have a pretty good opportunity now to experiment with it while nothing on your system made it useless without one. I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. The mess was created by people shouting 'hey, real men use separate /usr for no good reason! Be awesome like us'. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 10 Jan 2012 20:03:15 +0100 Michał Górny mgo...@gentoo.org wrote: The mess was created by people shouting 'hey, real men use separate /usr for no good reason! Be awesome like us'. You appear to be confusing I don't understand this with no-one understands this. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, Jan 10, 2012 at 1:56 PM, Dale rdalek1...@gmail.com wrote: Took me days to get dracut to work. Where does 15 minutes come from? How much time does it take when the initramfs fails? I've used dracut on a few VMs now and on my main Gentoo box. My experience has been that it didn't take long to figure out, and it is trivially easy to install. Now, whether it works is a separate issue. Most of the time it works just fine, and it is no harder to deploy than typing genkernel all. When it doesn't work then you're going to spend a whole lot more time trying to fix it - I'm still tweaking mine. Granted, its failure mode is only disastrous in an unattended system in my case since I can just type one line at the dash shell and exit and it boots fine. I just need to get unlazy and debug the script... Rich
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10.01.2012 19:56, Dale wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? Took me days to get dracut to work. Where does 15 minutes come from? How much time does it take when the initramfs fails? I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. Dale :-) :-) If you have got it working once, it should take less than 15 minutes (I've made myself a bashscript with the exact dracut commandline parameters needed for my system). But I have to agree with you, that exotic setups (I have encypted root on my laptop) are very bad documented. If dracut shall become standard for Gentoo (alternative: genkernel can build an initramfs) someone will have to write an exact howto with the most important (or better all) commandline arguments and kernel commandline parameters. Hinnerk -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPDIzWAAoJEJwwOFaNFkYccIUH/2sPXpD/nOyrMZi34eUgV8qp NVa/JvVUEiSdxpETJoahwNTT1tOilxXA5ospLK3FShDyMqmngaFtTp8dqaiojOwg OOcNkmq8/W6GUVrRUOfBjM1LORVOcGkGWAQ2RNkah388M7HCXe98bgKSd7vLJtbd E5deIZ8ETLaJ2+tQh1L3Af6D7hUlZolbwwmUGl7b81o6O1YFjkvaZFiNBBoSQ8rD h+OXxnsXn72xFIqek/egpPkUqHDRhtO4hvo6fJR5JZGpF8r1HeS3y4Fa/jFPVrtV EUsdkCulW5ZDQt0pXbWDOugMhEFtkJ3NMlZKUiqdKYiiZmJcmp1Rgu0NQYlw0uY= =bupg -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: On Tue, 10 Jan 2012 12:56:11 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? Took me days to get dracut to work. Where does 15 minutes come from? I just took the time I needed to write an initramfs from scratch and divided it by two, assuming using an already-made tool is simpler. Wish it was like that for me. I never got one made from scratch to work. How much time does it take when the initramfs fails? The same when rootfs fails? Only the fact that initramfs is less likely to break than rootfs, and you have a pretty good opportunity now to experiment with it while nothing on your system made it useless without one. Funny, I never had the rootfs fail before. I have had init thingys fail many many times. They lead to a reinstall since I had no idea how to fix it. I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. The mess was created by people shouting 'hey, real men use separate /usr for no good reason! Be awesome like us'. I think it is more like people do that when they have a good reason to do so. I plan to put mine on /usr when I get the chance and know that this init crap isn't going to break my rig. It's not being awesome either. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Rich Freeman wrote: On Tue, Jan 10, 2012 at 1:56 PM, Dalerdalek1...@gmail.com wrote: Took me days to get dracut to work. Where does 15 minutes come from? How much time does it take when the initramfs fails? I've used dracut on a few VMs now and on my main Gentoo box. My experience has been that it didn't take long to figure out, and it is trivially easy to install. Now, whether it works is a separate issue. Most of the time it works just fine, and it is no harder to deploy than typing genkernel all. When it doesn't work then you're going to spend a whole lot more time trying to fix it - I'm still tweaking mine. Granted, its failure mode is only disastrous in an unattended system in my case since I can just type one line at the dash shell and exit and it boots fine. I just need to get unlazy and debug the script... Rich I finally got dracut to work, I think it is anyway. I asked on the user list but no one knows I guess since there are no replies. I tried genkernel when I first installed Gentoo. I found it MUCH easier to do my own kernel. Genkernel never built a bootable kernel for my rig. I don't recall the errors now but it didn't work and I tried many times. I still do my kernels by hand. The thing about me is that I left my previous distro because of the init thingy CONSTANTLY failing and rpm dependency issues. Now, here I am again. By the way, I didn't mess with the init thingy either. It broke all on its own. This makes me wonder if the dependency issues has gotten sorted out. My brothers Kubuntu seems to work fine. It just makes me wonder. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Hinnerk van Bruinehsen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10.01.2012 19:56, Dale wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? Took me days to get dracut to work. Where does 15 minutes come from? How much time does it take when the initramfs fails? I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. Dale :-) :-) If you have got it working once, it should take less than 15 minutes (I've made myself a bashscript with the exact dracut commandline parameters needed for my system). But I have to agree with you, that exotic setups (I have encypted root on my laptop) are very bad documented. If dracut shall become standard for Gentoo (alternative: genkernel can build an initramfs) someone will have to write an exact howto with the most important (or better all) commandline arguments and kernel commandline parameters. Hinnerk -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPDIzWAAoJEJwwOFaNFkYccIUH/2sPXpD/nOyrMZi34eUgV8qp NVa/JvVUEiSdxpETJoahwNTT1tOilxXA5ospLK3FShDyMqmngaFtTp8dqaiojOwg OOcNkmq8/W6GUVrRUOfBjM1LORVOcGkGWAQ2RNkah388M7HCXe98bgKSd7vLJtbd E5deIZ8ETLaJ2+tQh1L3Af6D7hUlZolbwwmUGl7b81o6O1YFjkvaZFiNBBoSQ8rD h+OXxnsXn72xFIqek/egpPkUqHDRhtO4hvo6fJR5JZGpF8r1HeS3y4Fa/jFPVrtV EUsdkCulW5ZDQt0pXbWDOugMhEFtkJ3NMlZKUiqdKYiiZmJcmp1Rgu0NQYlw0uY= =bupg -END PGP SIGNATURE- If I recall correctly, it took me at least three or four web sites and the man page to get dracut to work. This is something that needs to be worked on hugely before this goes to much farther. Gentoo doesn't need to lose its status on the docs. I tried to follow the Gentoo doc and it would not even boot. I tried everything I could find but it still didn't work. Out of date, maybe. I dunno. It just didn't work for me. Thing is, my current setup doesn't even need one. I plan to have a separate /usr on LVM as soon as I can get me one more large drive. I'll have to have one then. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 10 Jan 2012 16:40:01 -0600 Dale rdalek1...@gmail.com wrote: I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. The mess was created by people shouting 'hey, real men use separate /usr for no good reason! Be awesome like us'. I think it is more like people do that when they have a good reason to do so. I plan to put mine on /usr when I get the chance and know that this init crap isn't going to break my rig. It's not being awesome either. Remind me of a single good reason. Last time I heard those were mostly hacks and laziness. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 08 Jan 2012 23:58:53 +0100 Michael Weber x...@gentoo.org wrote: Concern is to sustain the freedom of choice that brought me to Gentoo. Please provide systemd as an option. And provide sysvinit/openrc as an option. Do __not__ make an initrd mandatory. And I'd like to have the freedom of having a clean rootfs and system free of random static executables needed to mount /usr with random filesystems. Static linking is IMHO worse than making _initramfs_ mandatory. Or maybe do you have method to force rebuilds of packages dependant on static libraries? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Mon, Jan 9, 2012 at 12:22 AM, Michał Górny mgo...@gentoo.org wrote: On Sun, 08 Jan 2012 23:58:53 +0100 Michael Weber x...@gentoo.org wrote: Concern is to sustain the freedom of choice that brought me to Gentoo. Please provide systemd as an option. And provide sysvinit/openrc as an option. Do __not__ make an initrd mandatory. And I'd like to have the freedom of having a clean rootfs and system free of random static executables needed to mount /usr with random filesystems. Static linking is IMHO worse than making _initramfs_ mandatory. Or maybe do you have method to force rebuilds of packages dependant on static libraries? Do you have a method to force rebuilds of the initramfs? The argument you used against static linking was that my statically linked binary has a library with a data corruption bug and thus when I go to rescue my machine I might inadvertently delete everything. How is having the library in my initramfs any different (even dynamically linked?) -A -- Best regards, Michał Górny
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 8 Jan 2012 00:47:21 +0100 Lars Wendler polynomia...@gentoo.org wrote: Am Freitag 06 Januar 2012, 17:07:20 schrieb Alex Alexander: On Fri, Jan 06, 2012 at 08:35:32AM -0500, Rich Freeman wrote: On Thu, Jan 5, 2012 at 5:36 PM, Alex Alexander wi...@gentoo.org wrote: If people are really interested in keeping a tight, self contained root, we need to: - establish a [tight] list of software we consider critical for / - fix/patch software in that list so it can run without /usr there - create /bin = /usr/bin/ symlinks for above software (simplifies things if packages start hardcoding /usr/bin here and there) - move everything else in /usr/bin/ You're missing one thing: - establish a list of all the configurations that will actually work with this self-contained root I think this is why there is so much disagreement over whether this is a good move. If you have a really simple configuration, then the self-contained root concept works reasonably well (though apparently we'll have to heavily patch newer versions of udev or abandon it to sustain this). However, if you have a very complex configuration the current self-contained root is already broken and you need an initramfs anyway. For in-between cases things might work now but that is likely to change as upstream moves on. The binary distros don't have users tweaking their kernels and init scripts, so they basically have to design for worst-case. Gentoo can get away with designing for more of an average case since we just tell anybody with a complex case to go read a howto and configure what is necessary (and we like to do that stuff anyway). We can choose not to like it, but it sounds like maintaining a self-contained root for even the typical case will become untenable. Those who argue that having /usr on a separate partition simply shouldn't be supported are basically just saying that our self-contained root should include everything in /usr which seems to defeat the whole point of a self-contained root anyway. It seems to me that the most reasonable approach is to not force the issue, but not deviate greatly from upstream either. That means accepting that over time the rootfs will become less and less capable of working on its own, and immediately improving tools like dracut to overcome these limitations. Users who can get away with it can avoid using an initramfs, at least for a time. Sure, it is all open source, and Gentoo can swim upstream if we REALLY want to. However, this only works if developers are willing to spend the time constantly fixing upstream's tools. It sounds to me like the maintainers of packages like udev/systemd/etc want to actually move in the same direction as upstream so in practice I don't see that happening. Now, Gentoo is about choice, so one thing we should try to do as much as possible is understand the limitations of the various configurations and make it clear to users when they do and don't need an initramfs. To be honest, tight coupling worries me more than the /usr move, since that has a lot more potential to constrain the choices we can offer our users (which is a great deal of the value that Gentoo offers). I understand its advantages, but it seems somewhat contrary to the unix way. That's why I wrote tight list. I do not expect the self-contained root to be able to handle everything /usr (or a complete initramfs) would. What it could and couldn't do is something that needs to be decided, but some work is already done there - it's just a bit messy and incomplete and because most people don't care it keeps getting worse. The important thing here is to make a clear definition of where we draw the line and make sure things work the way we want them to. I agree with you in that at some point patching may become too time consuming, but I still believe that if we do this properly, with a well-defined plan and list of packages we want to keep in / (with symlinks to be compatible with whatever others are trying to do), we won't be alone in this. Gentoo may be one of the most hardcore power-user distros out there, but we're certainly not the only one. Now, if only we had people interested enough in doing this... :) I'm interested in everything which prevents such kind of insanity from Gentoo. So count me in as volunteer keeping /bin, /sbin and /lib in Gentoo and systemd away from it. As long as we keep trying and working hard I'm sure we can do the workload that might come across when blind upstreams start adopting those foolish systemd/GnomeOS ideas... From which point this was systemd/GnomeOS ideas? As far I can see, this was completely irrelevant, separate Fedora idea. But with scapegoat, everything seems better, doesn't it? Does working
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sat, Jan 07, 2012 at 08:01:17PM +0100, Enrico Weigelt wrote Great. Perhaps you could create some unusual setups (perhaps in a full-VM), so we can build an test platform on it. IIRC the main problem are scenarios where /usr is not available at boot, eg. has to be mounted from somewhere else (eg. NFS). So, our test platform should have such setups. I run with an interesting setup at home which could be a torture test for mounting. fdisk shows... Device Boot Start End Blocks Id System /dev/sda1 63 976768064 4883840015 Extended /dev/sda5 126 996029 497952 83 Linux /dev/sda6 996093 8819684 3911796 82 Linux swap / Solaris /dev/sda7 8819748 976768064 483974158+ 83 Linux sda1 is the entire harddrive sda5 is the 250 megabyte / partition using ext2fs (YES!) sda6 is the swap partition sda7 is the rest of the harddrive using reiserfs /opt, /var, /usr, and /tmp are are bindmounted from /home like so... /dev/sda5 / ext2 noatime,nodiratime,async 0 1 /dev/sda7 /home reiserfs noatime,nodiratime,async,notail 0 1 /home/bindmounts/opt/opt auto bind 0 0 /home/bindmounts/var/var auto bind 0 0 /home/bindmounts/usr/usr auto bind 0 0 /home/bindmounts/tmp/tmp auto bind 0 0 This allows me to... * use a really small / partition, without resorting to LVM * not worry about running out of space in other partitions * I started using it years ago when I had not decided which distro to use. I could wipe the contents of /opt, /var, /usr, and /tmp but keep my data, emails, etc, in my user directory and install another distro without blowing away my data. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
do you need udevd in runlevel boot at all (for sysvinit)?
Given either your kernel knows its root hardware device driver or has
an initrd to load needed modules to mount the root filesystem.
You can have CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y and let the
kernel create all the /dev/{sd,sr,hd}? device files needed for
/etc/init.d/{fsck,bootmisc,localmount} to check and mount /usr.
Normally you can start udevd after localmount and just right before
network, to persistent-network rename the interfaces.
On NFS_ROOT setups, you either have network by CONFIG_IP_PNP
(kernel-level ip autoconfiguration) and get your root fs from the DHCP
or you have an initrd which can mount /usr.
So, all you need udevd for is fancy-permissions/groups once a non-root
plugs in an USB drive (which is an multiuser-nightmare by itself).
It should be sufficient to load udevd after localmount has mounted
/usr udevd replays all the discoveries read from the kernel and
applies the permission/ownership rules.
Concern is to sustain the freedom of choice that brought me to Gentoo.
Please provide systemd as an option.
And provide sysvinit/openrc as an option.
Do __not__ make an initrd mandatory.
/* skip __ALL__ the systemd rants */
Thanks.
- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iF4EAREIAAYFAk8KH60ACgkQknrdDGLu8JANDwD/V+MvWXtn/yXcE1/nTQT7ZlMh
g+K/EHomildn5cuTNssA/1eu83i6vQee6YbOoGouyWOfKvAxMRM33nhrPc3qXOqc
=txiD
-END PGP SIGNATURE-
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 01/08/2012 02:58 PM, Michael Weber wrote:
Hi,
do you need udevd in runlevel boot at all (for sysvinit)?
Given either your kernel knows its root hardware device driver or has
an initrd to load needed modules to mount the root filesystem.
You can have CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y and let the
kernel create all the /dev/{sd,sr,hd}? device files needed for
/etc/init.d/{fsck,bootmisc,localmount} to check and mount /usr.
Normally you can start udevd after localmount and just right before
network, to persistent-network rename the interfaces.
On NFS_ROOT setups, you either have network by CONFIG_IP_PNP
(kernel-level ip autoconfiguration) and get your root fs from the DHCP
or you have an initrd which can mount /usr.
So, all you need udevd for is fancy-permissions/groups once a non-root
plugs in an USB drive (which is an multiuser-nightmare by itself).
It should be sufficient to load udevd after localmount has mounted
/usr udevd replays all the discoveries read from the kernel and
applies the permission/ownership rules.
Concern is to sustain the freedom of choice that brought me to Gentoo.
Please provide systemd as an option.
And provide sysvinit/openrc as an option.
Do __not__ make an initrd mandatory.
In any case, you won't need an initramfs unless /usr is on a separate
partition. Assuming that /usr is mounted before init starts, doesn't it
make sense to start udevd as early as possible, before modules, before
lvm, and before localmount? If we start udevd after localmount as you
suggest, wouldn't that imply that we don't support modular kernels?
--
Thanks,
Zac
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, 06 Jan 2012 22:58:58 -0800 Zac Medico zmed...@gentoo.org wrote: An alternative approach to a having a bulky initramfs recovery partition like yours would be to put the content of a livecd/usb recovery disk onto a spare partition, and configure your lean busybox initramfs to mount that as the root if something goes wrong with your real root. And busybox again. Busybox is awfully big even when all useless tools are disabled. klibc is the way to go if initramfs is not supposed to be completely functional. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, 6 Jan 2012 19:41:39 -0500 Walter Dnes waltd...@waltdnes.org wrote: In my 3 gig /usr directory, over 2 gigs are devoted to Gentoo-specific stuff that a binary distro like Redhat does not require. What do we do if /usr is read-only? Symlink or bindmount onto it? Remount read/write whenever necessary (i.e. when doing administrative tasks). And sharing binaries does *NOT* work in Gentoo, unless *EVERYBODY* has *IDENTICAL* machines, or else you drop down to the lowest common denominator. That's one of the main points about Gentoo. We don't use generic i686 code, we use code optimised for our machines. I'm not a Gentoo ricer, but here's a prime example... a 3 and 1/2 year old Dell Dimension 530 with an onboard Intel graphics chip. Right after the initial install (i686 code from the install CD), the onboard graphics could not handle NHL Gamecentre Live fullscreen (1920x1080). There would be constant stuttering. After I emerged system and world with -march=native -O2 -mfpmath=sse, it handles NHL Gamecentre Live fullscreen, and even a 1080p movie clip downloaded from Youtube. Fedora with generic i686 code would not work for me. Sharing is usually useful when everybody actually has identical machines. Also, there's '-mtune' switch in gcc. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
* Walter Dnes waltd...@waltdnes.org schrieb: On Fri, Jan 06, 2012 at 07:41:27PM +0100, Enrico Weigelt wrote This is just our donation, I'm hoping others will join in. For the actual development, half of the resources should be fine, but testing dozens of uncommon scenarios will eat up a multiple of that. I'm not a C programmer, bash is my forte. I'm retired, and I have a spare machine to play around with for testing. Contact me offline if I can help. Great. Perhaps you could create some unusual setups (perhaps in a full-VM), so we can build an test platform on it. IIRC the main problem are scenarios where /usr is not available at boot, eg. has to be mounted from somewhere else (eg. NFS). So, our test platform should have such setups. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 01/07/2012 07:58 AM, Zac Medico wrote: That seems like an awfully large initramfs to load into memory for every boot, just to have it wiped from memory after switching to the real root. It's fine as long as you're not trying to shave every last microsecond off of your boot time though. The size is 59MB, core2duo 2x2.20GHz, 44MB/s HDD needs approx 3 seconds reading from xfs /boot An alternative approach to a having a bulky initramfs recovery partition like yours would be to put the content of a livecd/usb recovery disk onto a spare partition, and configure your lean busybox initramfs to mount that as the root if something goes wrong with your real root. Yeah, i have full disk ecnryption and /boot is my recovery partition. I don't want to reboot or picup usb/optical media to fix problems. Well, and i can backup my system via nc/ssh/sshd/..., plus screen-lock. 3 seconds penalty on approx 50 boos/year are less time than standing up and search-rescue an potentially outdated external media. And yes, I decided against recompiled binaries (USE=-X) in favor of creation time (approx 3 minutes), that f**ks vim and nethack. Michael -- Gentoo Dev http://xmw.de/
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Am Freitag 06 Januar 2012, 17:07:20 schrieb Alex Alexander: On Fri, Jan 06, 2012 at 08:35:32AM -0500, Rich Freeman wrote: On Thu, Jan 5, 2012 at 5:36 PM, Alex Alexander wi...@gentoo.org wrote: If people are really interested in keeping a tight, self contained root, we need to: - establish a [tight] list of software we consider critical for / - fix/patch software in that list so it can run without /usr there - create /bin = /usr/bin/ symlinks for above software (simplifies things if packages start hardcoding /usr/bin here and there) - move everything else in /usr/bin/ You're missing one thing: - establish a list of all the configurations that will actually work with this self-contained root I think this is why there is so much disagreement over whether this is a good move. If you have a really simple configuration, then the self-contained root concept works reasonably well (though apparently we'll have to heavily patch newer versions of udev or abandon it to sustain this). However, if you have a very complex configuration the current self-contained root is already broken and you need an initramfs anyway. For in-between cases things might work now but that is likely to change as upstream moves on. The binary distros don't have users tweaking their kernels and init scripts, so they basically have to design for worst-case. Gentoo can get away with designing for more of an average case since we just tell anybody with a complex case to go read a howto and configure what is necessary (and we like to do that stuff anyway). We can choose not to like it, but it sounds like maintaining a self-contained root for even the typical case will become untenable. Those who argue that having /usr on a separate partition simply shouldn't be supported are basically just saying that our self-contained root should include everything in /usr which seems to defeat the whole point of a self-contained root anyway. It seems to me that the most reasonable approach is to not force the issue, but not deviate greatly from upstream either. That means accepting that over time the rootfs will become less and less capable of working on its own, and immediately improving tools like dracut to overcome these limitations. Users who can get away with it can avoid using an initramfs, at least for a time. Sure, it is all open source, and Gentoo can swim upstream if we REALLY want to. However, this only works if developers are willing to spend the time constantly fixing upstream's tools. It sounds to me like the maintainers of packages like udev/systemd/etc want to actually move in the same direction as upstream so in practice I don't see that happening. Now, Gentoo is about choice, so one thing we should try to do as much as possible is understand the limitations of the various configurations and make it clear to users when they do and don't need an initramfs. To be honest, tight coupling worries me more than the /usr move, since that has a lot more potential to constrain the choices we can offer our users (which is a great deal of the value that Gentoo offers). I understand its advantages, but it seems somewhat contrary to the unix way. That's why I wrote tight list. I do not expect the self-contained root to be able to handle everything /usr (or a complete initramfs) would. What it could and couldn't do is something that needs to be decided, but some work is already done there - it's just a bit messy and incomplete and because most people don't care it keeps getting worse. The important thing here is to make a clear definition of where we draw the line and make sure things work the way we want them to. I agree with you in that at some point patching may become too time consuming, but I still believe that if we do this properly, with a well-defined plan and list of packages we want to keep in / (with symlinks to be compatible with whatever others are trying to do), we won't be alone in this. Gentoo may be one of the most hardcore power-user distros out there, but we're certainly not the only one. Now, if only we had people interested enough in doing this... :) I'm interested in everything which prevents such kind of insanity from Gentoo. So count me in as volunteer keeping /bin, /sbin and /lib in Gentoo and systemd away from it. As long as we keep trying and working hard I'm sure we can do the workload that might come across when blind upstreams start adopting those foolish systemd/GnomeOS ideas... -- Lars Wendler (Polynomial-C) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, Jan 06, 2012 at 08:35:32AM -0500, Rich Freeman wrote: On Thu, Jan 5, 2012 at 5:36 PM, Alex Alexander wi...@gentoo.org wrote: If people are really interested in keeping a tight, self contained root, we need to: - establish a [tight] list of software we consider critical for / - fix/patch software in that list so it can run without /usr there - create /bin = /usr/bin/ symlinks for above software (simplifies things if packages start hardcoding /usr/bin here and there) - move everything else in /usr/bin/ You're missing one thing: - establish a list of all the configurations that will actually work with this self-contained root I think this is why there is so much disagreement over whether this is a good move. If you have a really simple configuration, then the self-contained root concept works reasonably well (though apparently we'll have to heavily patch newer versions of udev or abandon it to sustain this). However, if you have a very complex configuration the current self-contained root is already broken and you need an initramfs anyway. For in-between cases things might work now but that is likely to change as upstream moves on. The binary distros don't have users tweaking their kernels and init scripts, so they basically have to design for worst-case. Gentoo can get away with designing for more of an average case since we just tell anybody with a complex case to go read a howto and configure what is necessary (and we like to do that stuff anyway). We can choose not to like it, but it sounds like maintaining a self-contained root for even the typical case will become untenable. Those who argue that having /usr on a separate partition simply shouldn't be supported are basically just saying that our self-contained root should include everything in /usr which seems to defeat the whole point of a self-contained root anyway. It seems to me that the most reasonable approach is to not force the issue, but not deviate greatly from upstream either. That means accepting that over time the rootfs will become less and less capable of working on its own, and immediately improving tools like dracut to overcome these limitations. Users who can get away with it can avoid using an initramfs, at least for a time. Sure, it is all open source, and Gentoo can swim upstream if we REALLY want to. However, this only works if developers are willing to spend the time constantly fixing upstream's tools. It sounds to me like the maintainers of packages like udev/systemd/etc want to actually move in the same direction as upstream so in practice I don't see that happening. Now, Gentoo is about choice, so one thing we should try to do as much as possible is understand the limitations of the various configurations and make it clear to users when they do and don't need an initramfs. To be honest, tight coupling worries me more than the /usr move, since that has a lot more potential to constrain the choices we can offer our users (which is a great deal of the value that Gentoo offers). I understand its advantages, but it seems somewhat contrary to the unix way. That's why I wrote tight list. I do not expect the self-contained root to be able to handle everything /usr (or a complete initramfs) would. What it could and couldn't do is something that needs to be decided, but some work is already done there - it's just a bit messy and incomplete and because most people don't care it keeps getting worse. The important thing here is to make a clear definition of where we draw the line and make sure things work the way we want them to. I agree with you in that at some point patching may become too time consuming, but I still believe that if we do this properly, with a well-defined plan and list of packages we want to keep in / (with symlinks to be compatible with whatever others are trying to do), we won't be alone in this. Gentoo may be one of the most hardcore power-user distros out there, but we're certainly not the only one. Now, if only we had people interested enough in doing this... :) -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
* William Hubbs willi...@gentoo.org schrieb: Hi folks, a significant change is taking place with several upstreams that will affect us in gentoo, so I wanted to bring it to the list for discussion. Udev, kmod (which is a replacement for module-init-tools which will be needed by =udev-176), systemd, and soon others, are advocating a major change to the locations where binaries and libraries are stored on linux systems. The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My understanding is that they want to move software that is installed in /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move everything from /lib to /usr/lib. Yep, the same issue alreay came up a few weeks ago on @debian. I don't want to repeat all the arguments, why these Windows-imitator guys are completely wrong, anymore. (IMHO already been said in this thread). If upstream really wants to stick in that silly chance, it's time for a fork. We're already allocating about 20..30hrs per week beginning with 2012/2 for such a project in our resource plan. This stupidity can become really dangerous thousands of systems around the world, so it needs to be stopped. BTW: the original argument (AFAIK) is that moving everything to /usr should somehow make maintenance easier. Well, how actually ? Perhaps for people who are too lazy to backup a few more directories ? Silly. Actually, at this point, I'd raise the question why not dropping /usr instead (in little steps). The impact is practically the same (well, replaces the risk of unbootable system by the risk of filling up separated / filesystems) but would remove an then obsolete additional directory. ;-O cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, 6 Jan 2012 18:50:49 +0100 Enrico Weigelt weig...@metux.de wrote: I don't want to repeat all the arguments, why these Windows-imitator guys are completely wrong, anymore. (IMHO already been said in this thread). Yes, having a single locations for all applications is so-windows. We should go the other way then, and create a separate prefix for every application. I wonder why we removed that awesome /usr/X11R6. If upstream really wants to stick in that silly chance, it's time for a fork. We're already allocating about 20..30hrs per week beginning with 2012/2 for such a project in our resource plan. This stupidity can become really dangerous thousands of systems around the world, so it needs to be stopped. Wow, an enterprise fork taking 20-30 hrs per week to reimplement hacks necessary for running applications randomly spread over filesystems? BTW: the original argument (AFAIK) is that moving everything to /usr should somehow make maintenance easier. Well, how actually ? Perhaps for people who are too lazy to backup a few more directories ? Silly. Enjoy sharing those few more directories over NFS. Ah, yes, only silly people want to share their systems over NFS. Enterprise admins reserve 20-30 hrs per week to keep systems in sync. Actually, at this point, I'd raise the question why not dropping /usr instead (in little steps). The impact is practically the same (well, replaces the risk of unbootable system by the risk of filling up separated / filesystems) but would remove an then obsolete additional directory. ;-O That's because people would like to get rid of additional directories in /, not introduce additional ones. But if you really want to, we can start making random packages install on rootfs. Just let us know when they happily fill up your rootfs. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
* Patrick Lauer patr...@gentoo.org schrieb: Please don't try to bring the GnomeOS vision of having MacOS without paying for it to my computing experience ... +10 cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
* Micha?? G?rny mgo...@gentoo.org schrieb: I don't want to repeat all the arguments, why these Windows-imitator guys are completely wrong, anymore. (IMHO already been said in this thread). Yes, having a single locations for all applications is so-windows. We should go the other way then, and create a separate prefix for every application. I wonder why we removed that awesome /usr/X11R6. I was talking about other things, like giving up the typical unix-style separation of subsystems, all the bloating happening in certain DE's and then pulling down that bloat to the system level (just starting w/ dbus) If upstream really wants to stick in that silly chance, it's time for a fork. We're already allocating about 20..30hrs per week beginning with 2012/2 for such a project in our resource plan. This stupidity can become really dangerous thousands of systems around the world, so it needs to be stopped. Wow, an enterprise fork taking 20-30 hrs per week to reimplement hacks necessary for running applications randomly spread over filesystems? This is just our donation, I'm hoping others will join in. For the actual development, half of the resources should be fine, but testing dozens of uncommon scenarios will eat up a multiple of that. BTW: the original argument (AFAIK) is that moving everything to /usr should somehow make maintenance easier. Well, how actually ? Perhaps for people who are too lazy to backup a few more directories ? Silly. Enjoy sharing those few more directories over NFS. Yes, what's the big deal ? Done that with thousands of nodes. Actually, at this point, I'd raise the question why not dropping /usr instead (in little steps). The impact is practically the same (well, replaces the risk of unbootable system by the risk of filling up separated / filesystems) but would remove an then obsolete additional directory. ;-O That's because people would like to get rid of additional directories in /, not introduce additional ones. Aha. Then why not also moving /home, /etc and /var to /usr, too ? ;-o (hmm, some mindless jerks really could pick up that silly idea...) cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, 6 Jan 2012 19:41:27 +0100 Enrico Weigelt weig...@metux.de wrote: * Micha?? G?rny mgo...@gentoo.org schrieb: I don't want to repeat all the arguments, why these Windows-imitator guys are completely wrong, anymore. (IMHO already been said in this thread). Yes, having a single locations for all applications is so-windows. We should go the other way then, and create a separate prefix for every application. I wonder why we removed that awesome /usr/X11R6. I was talking about other things, like giving up the typical unix-style separation of subsystems, all the bloating happening in certain DE's and then pulling down that bloat to the system level (just starting w/ dbus) Yes, three arguments and just a one, silly example which is basically incorrect assuming noone obliges you to use systemd. If upstream really wants to stick in that silly chance, it's time for a fork. We're already allocating about 20..30hrs per week beginning with 2012/2 for such a project in our resource plan. This stupidity can become really dangerous thousands of systems around the world, so it needs to be stopped. Wow, an enterprise fork taking 20-30 hrs per week to reimplement hacks necessary for running applications randomly spread over filesystems? This is just our donation, I'm hoping others will join in. For the actual development, half of the resources should be fine, but testing dozens of uncommon scenarios will eat up a multiple of that. I thought you reserved that much time for mailing lists. BTW: the original argument (AFAIK) is that moving everything to /usr should somehow make maintenance easier. Well, how actually ? Perhaps for people who are too lazy to backup a few more directories ? Silly. Enjoy sharing those few more directories over NFS. Yes, what's the big deal ? Done that with thousands of nodes. Without initramfs? Syncing rootfs over and over again or just updating packages installing into it once a year? Actually, at this point, I'd raise the question why not dropping /usr instead (in little steps). The impact is practically the same (well, replaces the risk of unbootable system by the risk of filling up separated / filesystems) but would remove an then obsolete additional directory. ;-O That's because people would like to get rid of additional directories in /, not introduce additional ones. Aha. Then why not also moving /home, /etc and /var to /usr, too ? ;-o (hmm, some mindless jerks really could pick up that silly idea...) You should consider taking like 1 or 2 hours of your precious time to read about the use and meaning of various directories in the filesystem. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
* Micha?? G?rny mgo...@gentoo.org schrieb: I was talking about other things, like giving up the typical unix-style separation of subsystems, all the bloating happening in certain DE's and then pulling down that bloat to the system level (just starting w/ dbus) Yes, three arguments and just a one, silly example which is basically incorrect assuming noone obliges you to use systemd. IIRC, systemd is not the only system-level package depending on dbus. Yes, what's the big deal ? Done that with thousands of nodes. Without initramfs? Yes. Using PXE and nfsroot. Syncing rootfs over and over again or just updating packages installing into it once a year? Regularily updating packages, but with quite conservative policy. Of course, this required proper service restarts, etc, but thats an topic on its own ... That's because people would like to get rid of additional directories in /, not introduce additional ones. Aha. Then why not also moving /home, /etc and /var to /usr, too ? ;-o (hmm, some mindless jerks really could pick up that silly idea...) You should consider taking like 1 or 2 hours of your precious time to read about the use and meaning of various directories in the filesystem. I studied FHS and its purpose somewhat 15 years ago, and I don't want to repeat all the arguments. My argument was just: if you wanna move /bin+co to /usr for easier maintenance, you could also put /usr/* to / for quite the same reasons. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 04, 2012 at 01:51:26PM -0500, Olivier Cr?te wrote No no no, the idea is that once all binaries are in /usr, you can easily share /usr between different systems and do updates in a sane way.. You can also mount /usr read-only, but still have / be read-write. One size does not fit all. It breaks Gentoo horribly. Here's my setup waltdnes@d530 / $ du -s /usr 3057917 usr waltdnes@d530 /usr $ du -s /usr/portage 1394646 /usr/portage waltdnes@d530 /usr $ du -s /usr/src 665069 /usr/src In my 3 gig /usr directory, over 2 gigs are devoted to Gentoo-specific stuff that a binary distro like Redhat does not require. What do we do if /usr is read-only? Symlink or bindmount onto it? And sharing binaries does *NOT* work in Gentoo, unless *EVERYBODY* has *IDENTICAL* machines, or else you drop down to the lowest common denominator. That's one of the main points about Gentoo. We don't use generic i686 code, we use code optimised for our machines. I'm not a Gentoo ricer, but here's a prime example... a 3 and 1/2 year old Dell Dimension 530 with an onboard Intel graphics chip. Right after the initial install (i686 code from the install CD), the onboard graphics could not handle NHL Gamecentre Live fullscreen (1920x1080). There would be constant stuttering. After I emerged system and world with -march=native -O2 -mfpmath=sse, it handles NHL Gamecentre Live fullscreen, and even a 1080p movie clip downloaded from Youtube. Fedora with generic i686 code would not work for me. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, 2012-01-06 at 19:41 -0500, Walter Dnes wrote: On Wed, Jan 04, 2012 at 01:51:26PM -0500, Olivier Cr?te wrote No no no, the idea is that once all binaries are in /usr, you can easily share /usr between different systems and do updates in a sane way.. You can also mount /usr read-only, but still have / be read-write. One size does not fit all. It breaks Gentoo horribly. Here's my setup waltdnes@d530 / $ du -s /usr 3057917 usr waltdnes@d530 /usr $ du -s /usr/portage 1394646 /usr/portage waltdnes@d530 /usr $ du -s /usr/src 665069 /usr/src In my 3 gig /usr directory, over 2 gigs are devoted to Gentoo-specific stuff that a binary distro like Redhat does not require. What do we do if /usr is read-only? Symlink or bindmount onto it? You don't understand the purpose of read-only /usr. It has nothing to do with source vs binary. It is for when you have many machines that are identical or at least similar. The idea is that you can mount the same /usr on many machines (using NFS or something like that). So you can have a relatively small / as a r/w nfsroot (containing /etc, /var, /tmp, etc, etc), and then share /usr among all the machines in your cluster or machine room or your many user desktops. With the current system, you either have to maintain in sync the /bin, /sbin, /usr, etc separately, making life harder for everyone. But clearly, you've never been the sysadmin of that kind of setup. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, Jan 06, 2012 at 07:41:27PM +0100, Enrico Weigelt wrote This is just our donation, I'm hoping others will join in. For the actual development, half of the resources should be fine, but testing dozens of uncommon scenarios will eat up a multiple of that. I'm not a C programmer, bash is my forte. I'm retired, and I have a spare machine to play around with for testing. Contact me offline if I can help. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, 06 Jan 2012 19:59:45 -0500 Olivier Crête tes...@gentoo.org wrote: On Fri, 2012-01-06 at 19:41 -0500, Walter Dnes wrote: On Wed, Jan 04, 2012 at 01:51:26PM -0500, Olivier Cr?te wrote No no no, the idea is that once all binaries are in /usr, you can easily share /usr between different systems and do updates in a sane way.. You can also mount /usr read-only, but still have / be read-write. One size does not fit all. It breaks Gentoo horribly. Here's my setup waltdnes@d530 / $ du -s /usr 3057917 usr waltdnes@d530 /usr $ du -s /usr/portage 1394646 /usr/portage waltdnes@d530 /usr $ du -s /usr/src 665069 /usr/src In my 3 gig /usr directory, over 2 gigs are devoted to Gentoo-specific stuff that a binary distro like Redhat does not require. What do we do if /usr is read-only? Symlink or bindmount onto it? You don't understand the purpose of read-only /usr. It has nothing to do with source vs binary. It is for when you have many machines that are identical or at least similar. The idea is that you can mount the same /usr on many machines (using NFS or something like that). So you can have a relatively small / as a r/w nfsroot (containing /etc, /var, /tmp, etc, etc), and then share /usr among all the machines in your cluster or machine room or your many user desktops. With the current system, you either have to maintain in sync the /bin, /sbin, /usr, etc separately, making life harder for everyone. But clearly, you've never been the sysadmin of that kind of setup. Not saying it's just you, but people should stop being dicks. Being antagonistic against everyone is not getting us anywhere and only serves to divide the community. People shouldn't use the hate in dealing with whether or not to change on other people, use it on the actual argument :D -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 01/05/2012 03:40 AM, Zac Medico wrote: The FHS notion of root filesystem as a recovery partition existed long before the relatively modern development of things like busybox and initramfs made it more practical to use an initramfs as a recovery partition. Anyone who wouldn't prefer to use an initramfs for their recover partition probably just doesn't realize how well suited an initramfs is for the job. It's so well suited for the job that it makes the old FHS notion of root filesystem as a recovery partition seem quaint. Please stop hailing to busybox. I think it's a bulk load of faulty, half implemented code that's not worth the time compiling. You can do better w/ the real tools. (Not my crappy little initrd script, but the well established, fully operational, as used to programms) http://xmw.de/dotfiles/scripts/mkinitramfs.sh -- Gentoo Dev http://xmw.de/
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 01/06/2012 07:10 PM, Michael Weber wrote: On 01/05/2012 03:40 AM, Zac Medico wrote: The FHS notion of root filesystem as a recovery partition existed long before the relatively modern development of things like busybox and initramfs made it more practical to use an initramfs as a recovery partition. Anyone who wouldn't prefer to use an initramfs for their recover partition probably just doesn't realize how well suited an initramfs is for the job. It's so well suited for the job that it makes the old FHS notion of root filesystem as a recovery partition seem quaint. Please stop hailing to busybox. I think it's a bulk load of faulty, half implemented code that's not worth the time compiling. You can do better w/ the real tools. (Not my crappy little initrd script, but the well established, fully operational, as used to programms) http://xmw.de/dotfiles/scripts/mkinitramfs.sh That seems like an awfully large initramfs to load into memory for every boot, just to have it wiped from memory after switching to the real root. It's fine as long as you're not trying to shave every last microsecond off of your boot time though. An alternative approach to a having a bulky initramfs recovery partition like yours would be to put the content of a livecd/usb recovery disk onto a spare partition, and configure your lean busybox initramfs to mount that as the root if something goes wrong with your real root. -- Thanks, Zac
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, Jan 05, 2012 at 07:27:49AM +1300, Kent Fredric wrote: 2012/1/5 Ulrich Mueller u...@gentoo.org On Wed, 4 Jan 2012, Michał Górny wrote: There's really nothing pointless or blurry about this separation. The FHS has a nice definition: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Given that these tools are being moved to /usr and/or duplicated to in initrd , what is the point of a root filesystem anyway now? Just to mount other things on? Just to store /etc ? Or will /etc move to /usr too? No, /etc isn't going anywhere. William pgpI7nEAbZXVR.pgp Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, Jan 5, 2012 at 3:08 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Are you sure? I heard a rumour that systemd will soon require you to put /etc inside your initrd (since / can't be mounted without it). While I can't speak to your comments about being unable to restart daemons with systemd (hope this isn't the case, obviously), dracut does in fact include a copy of some files in /etc like mdadm.conf. So, if you reconfigure your raid it might be beneficial to rebuild your initramfs. As you might expect that is optional - mdadm can more-or-less work without mdadm.conf, but in some cases you could have your raids change name and such. If you mount root by UUID that won't prevent you from booting, but it might mess up your own scripts if you refer to md devices by number. Rich
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, Jan 05, 2012 at 08:08:44PM +, Ciaran McCreesh wrote: Or will /etc move to /usr too? No, /etc isn't going anywhere. Are you sure? I heard a rumour that systemd will soon require you to put /etc inside your initrd (since / can't be mounted without it). Obviously, you'd have to reboot if you made any changes to your config files, but that's OK since you can't safely restart daemons anyway. They've thought of that, and will make - kexec mandatory so that reboots are not needed for those times you need to switch kernels - make hibernation mandatory for the other times
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, 2012-01-05 at 20:08 +, Ciaran McCreesh wrote: On Thu, 5 Jan 2012 13:30:24 -0600 William Hubbs willi...@gentoo.org wrote: Or will /etc move to /usr too? No, /etc isn't going anywhere. Are you sure? I heard a rumour that systemd will soon require you to put /etc inside your initrd (since / can't be mounted without it). Obviously, you'd have to reboot if you made any changes to your config files, but that's OK since you can't safely restart daemons anyway. Dude, the systemd people are not crazy. You should try to understand what they do before criticizing. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, 05 Jan 2012 16:02:09 -0500 Olivier Crête tes...@gentoo.org wrote: On Thu, 2012-01-05 at 20:08 +, Ciaran McCreesh wrote: On Thu, 5 Jan 2012 13:30:24 -0600 William Hubbs willi...@gentoo.org wrote: Or will /etc move to /usr too? No, /etc isn't going anywhere. Are you sure? I heard a rumour that systemd will soon require you to put /etc inside your initrd (since / can't be mounted without it). Obviously, you'd have to reboot if you made any changes to your config files, but that's OK since you can't safely restart daemons anyway. Dude, the systemd people are not crazy. You should try to understand what they do before criticizing. I don't claim they're crazy. I claim they're sacrificing functionality, correctness, loose coupling, simplicity, well defined behaviour, understandability and stability in order to implement questionable new shiny things. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, 2012-01-05 at 21:09 +, Ciaran McCreesh wrote: On Thu, 05 Jan 2012 16:02:09 -0500 Olivier Crête tes...@gentoo.org wrote: On Thu, 2012-01-05 at 20:08 +, Ciaran McCreesh wrote: On Thu, 5 Jan 2012 13:30:24 -0600 William Hubbs willi...@gentoo.org wrote: Or will /etc move to /usr too? No, /etc isn't going anywhere. Are you sure? I heard a rumour that systemd will soon require you to put /etc inside your initrd (since / can't be mounted without it). Obviously, you'd have to reboot if you made any changes to your config files, but that's OK since you can't safely restart daemons anyway. Dude, the systemd people are not crazy. You should try to understand what they do before criticizing. I don't claim they're crazy. I claim they're sacrificing functionality, correctness, loose coupling, simplicity, well defined behaviour, understandability and stability in order to implement questionable new shiny things. The only thing I see them sacrificing is loose coupling, they provide more functionality than any other init system, more correctness (seriously, did you ever read most init scripts out there?), more well defined behavior (all systemd systems boot exactly the same), more stability (I'll claim that Lennart's C is better than any of the boot-time shell scripts I've seen) and well understandability depends who much you can understand C. Probably a bit less understandable for sysadmins, but since they can just play with config files, it's probably easier to understand in the end (and much less prone to breaking than mucking around shell scripts). -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, 5 Jan 2012 21:09:35 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 05 Jan 2012 16:02:09 -0500 Olivier Crête tes...@gentoo.org wrote: On Thu, 2012-01-05 at 20:08 +, Ciaran McCreesh wrote: On Thu, 5 Jan 2012 13:30:24 -0600 William Hubbs willi...@gentoo.org wrote: Or will /etc move to /usr too? No, /etc isn't going anywhere. Are you sure? I heard a rumour that systemd will soon require you to put /etc inside your initrd (since / can't be mounted without it). Obviously, you'd have to reboot if you made any changes to your config files, but that's OK since you can't safely restart daemons anyway. Dude, the systemd people are not crazy. You should try to understand what they do before criticizing. I don't claim they're crazy. I claim they're sacrificing functionality, correctness, loose coupling, simplicity, well defined behaviour, understandability and stability in order to implement questionable new shiny things. Are you talking about the /usr move, systemd or udev now? Or just throwing random nouns to prove some random point? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, 5 Jan 2012 23:06:18 +0100 Michał Górny mgo...@gentoo.org wrote: I don't claim they're crazy. I claim they're sacrificing functionality, correctness, loose coupling, simplicity, well defined behaviour, understandability and stability in order to implement questionable new shiny things. Are you talking about the /usr move, systemd or udev now? Or just throwing random nouns to prove some random point? I'm talking about the GnomeOS concept, which involves all of those. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, Jan 05, 2012 at 08:08:44PM +, Ciaran McCreesh wrote: On Thu, 5 Jan 2012 13:30:24 -0600 William Hubbs willi...@gentoo.org wrote: Or will /etc move to /usr too? No, /etc isn't going anywhere. Are you sure? I heard a rumour that systemd will soon require you to put /etc inside your initrd (since / can't be mounted without it). Obviously, you'd have to reboot if you made any changes to your config files, but that's OK since you can't safely restart daemons anyway. Although this is a bit frightening to think about, because people are crazy enough to actually implement it, this is one of the funniest things I've read lately, thanks for the laugh xD On a serious note though, it seems to me that the /bin | /usr/bin line is too blurry, creating confusion. Migrating everything to a single folder is the simplest solution of all. Combine that with redhat's update approach and it is easy to see why they've taken this route. If people are really interested in keeping a tight, self contained root, we need to: - establish a [tight] list of software we consider critical for / - fix/patch software in that list so it can run without /usr there - create /bin = /usr/bin/ symlinks for above software (simplifies things if packages start hardcoding /usr/bin here and there) - move everything else in /usr/bin/ Do this and I'm sure other people/distros will follow/help and upstreams will accept our patches. I'm sure there are other people who don't like this one bin folder to rule them all logic. If no one is really interested in doing all this... well, whoever actually implements something in open source usually wins the race - it's the same in Gentoo too, no? ;) Only difference here is, one team has the advantage of being paid to do it. -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 01/06/12 05:26, Olivier Crête wrote: [snip] The only thing I see them sacrificing is loose coupling, they provide more functionality than any other init system, more correctness (seriously, did you ever read most init scripts out there?), more well defined behavior (all systemd systems boot exactly the same), more stability (I'll claim that Lennart's C is better than any of the boot-time shell scripts I've seen) and well understandability depends who much you can understand C. Probably a bit less understandable for sysadmins, but since they can just play with config files, it's probably easier to understand in the end (and much less prone to breaking than mucking around shell scripts). As you apparently have no idea what a sysadmin does I'd appreciate it if people like you didn't try to guess what would make things better and instead listened to people that have more than their desktop to run. (Hint: It's not pressing reset buttons) Given the choice between a single line of shell ( cat $urandom_seed /dev/urandom ) or 145 lines of undocumented C (which, if naively modified by me, might just make systemd segfault) ... there is no choice. I do agree with you on one point - most init scripts are really bad code, but that doesn't mean shell is bad, it means that you need to educate people and file bugs. I've laughed at SLES' /etc/bashrc, I read most of upstart and wondered how ... why ... is it can be drunk tiem? Still that doesn't mean that rewriting it in bad C is in any way more agreeable, and you just made debugging exquisitely painful. Yey.
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 6 January 2012 06:14, Patrick Lauer patr...@gentoo.org wrote: On 01/06/12 05:26, Olivier Crête wrote: [snip] The only thing I see them sacrificing is loose coupling, they provide more functionality than any other init system, more correctness (seriously, did you ever read most init scripts out there?), more well defined behavior (all systemd systems boot exactly the same), more stability (I'll claim that Lennart's C is better than any of the boot-time shell scripts I've seen) and well understandability depends who much you can understand C. Probably a bit less understandable for sysadmins, but since they can just play with config files, it's probably easier to understand in the end (and much less prone to breaking than mucking around shell scripts). As you apparently have no idea what a sysadmin does I'd appreciate it if people like you didn't try to guess what would make things better and instead listened to people that have more than their desktop to run. (Hint: It's not pressing reset buttons) Given the choice between a single line of shell ( cat $urandom_seed /dev/urandom ) or 145 lines of undocumented C (which, if naively modified by me, might just make systemd segfault) ... there is no choice. Seems straightforward and well-documented to me: http://cgit.freedesktop.org/systemd/tree/src/random-seed.c. And the if I naively modify things, they might explode argument holds for anything. These are basic things that you almost certainly would not be modifying as a sysadmin anyway. I'd hope that the things that you really do want to muck around with are provided as configuration, and if they're not, you talk to upstream and make a case for this being useful to users. Just like with every other open source project. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, 2012-01-06 at 08:44 +0800, Patrick Lauer wrote: On 01/06/12 05:26, Olivier Crête wrote: [snip] The only thing I see them sacrificing is loose coupling, they provide more functionality than any other init system, more correctness (seriously, did you ever read most init scripts out there?), more well defined behavior (all systemd systems boot exactly the same), more stability (I'll claim that Lennart's C is better than any of the boot-time shell scripts I've seen) and well understandability depends who much you can understand C. Probably a bit less understandable for sysadmins, but since they can just play with config files, it's probably easier to understand in the end (and much less prone to breaking than mucking around shell scripts). As you apparently have no idea what a sysadmin does I'd appreciate it if people like you didn't try to guess what would make things better and instead listened to people that have more than their desktop to run. (Hint: It's not pressing reset buttons) I know what they do.. play in random scripts until whatever they're trying to hack together it seems to work, because oh well, its just a one time thing.. and then when stuff breaks they call Red Hat's support line. Given the choice between a single line of shell ( cat $urandom_seed /dev/urandom ) or 145 lines of undocumented C (which, if naively modified by me, might just make systemd segfault) ... there is no choice. Actually, you don't have to do that, systemd does it for you and takes care of all the annoying details [1]. That said, you can trivially disable systemd-random-seed-save.service and systemd-random-seed-load.service and instead write a unit file that runs whatever you want. You don't HAVE to do any C to run stuff from systemd, but it does provide many things written in C that are much more solid than the shell equivalents. I do agree with you on one point - most init scripts are really bad code, but that doesn't mean shell is bad, it means that you need to educate people and file bugs. I've laughed at SLES' /etc/bashrc, I read most of upstart and wondered how ... why ... is it can be drunk tiem? Still that doesn't mean that rewriting it in bad C is in any way more agreeable, and you just made debugging exquisitely painful. Yey. The big reason for C vs shell scripts is that the type of people who write them are not the same.. The type of people who write shell scripts tend to hack together stuff until it works. The people who write C tend to think about the problem for a long time and then write a complete solution that tries to take into account all of the possible error scenarios. [1] http://cgit.freedesktop.org/systemd/tree/src/random-seed.c -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny schrieb: On Wed, 04 Jan 2012 01:47:38 +0100 Thomas Sachau to...@gentoo.org wrote: 2. switching from udev to mdev (avoids required /usr of udev) 3. some wrapper script to mount /usr before udev starts These two should be really discouraged as a cheap, temporary solution. We should not support hate-admining. I personally think that busybox is ready to go into /usr even earlier than udev. Please give us a bit more than just your opinion. Why do you see mdev as a temporary solution? And this part was not about the movement to /usr at all, so why do you suggest another movement here? And while you answer that, please also tell us, why you want to migrate packages to a different install location without a need. For the idea of complete migration to /usr, i see no reason to go this route in advance. Just keep with our default install locations and follow upstream, if and where needed. What about upstreams who do not care? In other words, all those packages which we hack to install into rootfs? They install and work fine, so just keep it this way. I did not see any argument to move packages around, that work well and have no issue with their current install location. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 3 January 2012 15:21, Walter Dnes waltd...@waltdnes.org wrote: On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote I see three options: 1) Start migrating packages along with upstream and have everyone who has a separate /usr (including me by the way) start using an initramfs of some kind, either dracut or one that we generate specifically for gentoo. The reason I suggest the initramfs, is, unfortunately if we migrate everything, nothing else would work. 2) Combine the sbin and bin directories both on the root filesystem and in /usr by moving things from /sbin to /bin and /usr/sbin to /usr/bin. 3) Try to maintain things the way they are as long as possible. 4) Following pointers from Zac Medico and others, I've managed to get Gentoo running with busybox's mdev, instead of udev. See http://archives.gentoo.org/gentoo-user/msg_bc91b392ee0f76376104591cdf7dc5f0.xml Executive summary... look Ma; no udev! Does mdev support all the rules we have in /lib/udev/rules.d/? The Internet is surprisingly mute on this subject, but a quick grep through the busybox source doesn't turn up anything that suggests that it might. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 7:58 AM, Arun Raghavan ford_pref...@gentoo.org wrote: Does mdev support all the rules we have in /lib/udev/rules.d/? The Internet is surprisingly mute on this subject, but a quick grep through the busybox source doesn't turn up anything that suggests that it might. I think the main use case for mdev is to do a one-time creation of typical device nodes with minimal use of resources. Perhaps you might say mdev is to udev as dash is to bash (though dash is syntax-compatible with bash, or at least it aims to be, and I'm not sure the same is true of mdev vs udev). If you're running a server or embedded device and you just need it to detect your hard drives and maybe a few devices you're willing to write scripts for, then it is a perfect choice. I have no idea how well it supports hotplugging of usb devices and such. For a desktop - it seems like a poor choice. By the time you enhanced it to do everything udev does you'll ruin it for embedded use and probably be stuck with all the same issues we have with udev. Fork udev if you must (good luck with that), but I don't really see mdev as being a real competitor. By all means write up an mdev howto and link it in the embedded guide or if enough users are passionate about it perhaps even link it in the handbook (as an alternative for adventurous users with special needs). However, I just can't see it ever becoming the default on a general-purpose distro like Gentoo (which aims to be all things to all people as much as is supportable). Certainly it is in the spirit of Gentoo to support it as an option for those willing to deal with the downsides (don't expect your bluetooth keyboard to work automagically, etc). Rich
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 6:43 PM, Rich Freeman ri...@gentoo.org wrote: On Wed, Jan 4, 2012 at 7:58 AM, Arun Raghavan ford_pref...@gentoo.org wrote: Does mdev support all the rules we have in /lib/udev/rules.d/? The Internet is surprisingly mute on this subject, but a quick grep through the busybox source doesn't turn up anything that suggests that it might. I think the main use case for mdev is to do a one-time creation of typical device nodes with minimal use of resources. In that case, you don't need a userspace daemon at all. Just use devtmpfs. That'll use even lower resources. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 04 Jan 2012 13:06:11 +0100 Thomas Sachau to...@gentoo.org wrote: Michał Górny schrieb: On Wed, 04 Jan 2012 01:47:38 +0100 Thomas Sachau to...@gentoo.org wrote: 2. switching from udev to mdev (avoids required /usr of udev) 3. some wrapper script to mount /usr before udev starts These two should be really discouraged as a cheap, temporary solution. We should not support hate-admining. I personally think that busybox is ready to go into /usr even earlier than udev. Please give us a bit more than just your opinion. Why do you see mdev as a temporary solution? Because we will then return to this discussion at some later point and people will start throwing excrements at us again. So let's be done with this at once. And this part was not about the movement to /usr at all, so why do you suggest another movement here? And while you answer that, please also tell us, why you want to migrate packages to a different install location without a need. Because we need to finally be able to fix mistakes made in the past by other people. For the idea of complete migration to /usr, i see no reason to go this route in advance. Just keep with our default install locations and follow upstream, if and where needed. What about upstreams who do not care? In other words, all those packages which we hack to install into rootfs? They install and work fine, so just keep it this way. I did not see any argument to move packages around, that work well and have no issue with their current install location. What if, say, upstream introduces pkg-config file where our hacks will cause it to be installed into /lib/pkgconfig? Should we then expand the hack to cover that, and something else, and then another thing... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 04-01-2012 16:37:34 +0100, Michał Górny wrote: And this part was not about the movement to /usr at all, so why do you suggest another movement here? And while you answer that, please also tell us, why you want to migrate packages to a different install location without a need. Because we need to finally be able to fix mistakes made in the past by other people. What mistakes? They install and work fine, so just keep it this way. I did not see any argument to move packages around, that work well and have no issue with their current install location. What if, say, upstream introduces pkg-config file where our hacks will cause it to be installed into /lib/pkgconfig? Should we then expand the hack to cover that, and something else, and then another thing... Highly unlikely, but if it happens, easy to fix, so not really a convincing issue. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 4 Jan 2012 17:33:15 +0100 Fabian Groffen grob...@gentoo.org wrote: On 04-01-2012 16:37:34 +0100, Michał Górny wrote: And this part was not about the movement to /usr at all, so why do you suggest another movement here? And while you answer that, please also tell us, why you want to migrate packages to a different install location without a need. Because we need to finally be able to fix mistakes made in the past by other people. What mistakes? The mistake of introducing a pointless separation based on a rule of thumb which becomes more and more blurry over time, and hacking packages just to make it work. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 4 Jan 2012, Michał Górny wrote: What mistakes? The mistake of introducing a pointless separation based on a rule of thumb which becomes more and more blurry over time, and hacking packages just to make it work. There's really nothing pointless or blurry about this separation. The FHS has a nice definition: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Ulrich
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 2012-01-04 at 18:12 +0100, Ulrich Mueller wrote: On Wed, 4 Jan 2012, Michał Górny wrote: What mistakes? The mistake of introducing a pointless separation based on a rule of thumb which becomes more and more blurry over time, and hacking packages just to make it work. There's really nothing pointless or blurry about this separation. The FHS has a nice definition: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. The problem is that to boot a modern system, you need a shitload of stuff. For example, modern network filesystems often have secure authentication and probably LDAP too, so that means we need to move ldap and openssl into / and all the dependencies. Also, anything that installs a udev rule needs to be in /, and the list goes on an on. Very soon, you have almost everything in /... This rule made sense in the 80s, but it doesn't match the modern world anymore. Some longer explanations: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken https://fedoraproject.org/wiki/Features/UsrMove Here is a list of packages on your system that will break if you start udev without /usr mounted: egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/* |cut -f 1 -d : | sort -u | xargs qfile -e -- Olivier Crête tes...@gentoo.org Gentoo Developer
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
* Olivier Crête schrieb am 04.01.12 um 18:32 Uhr: On Wed, 2012-01-04 at 18:12 +0100, Ulrich Mueller wrote: On Wed, 4 Jan 2012, Michał Górny wrote: What mistakes? The mistake of introducing a pointless separation based on a rule of thumb which becomes more and more blurry over time, and hacking packages just to make it work. There's really nothing pointless or blurry about this separation. The FHS has a nice definition: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. The problem is that to boot a modern system, you need a shitload of stuff. To boot the system on its highest level: yes. But Linux/UNIX systems have a concept called runlevels that can perfectly cover cases where this shitload of stuff is not required. For example, to make that FHS definition be reality there are (can be) runlevels that will only boot a system with all basic stuff required to mount the rootfs and make root being able to login to the local text console. These are the things that make a unixoid system valuable over other kind of systems. For example, modern network filesystems often have secure authentication and probably LDAP too, so that means we need to move ldap and openssl into / and all the dependencies. Also, anything that installs a udev rule needs to be in /, and the list goes on an on. Very soon, you have almost everything in /... You do not need everything to make a system boot some sort of recovery-console for example. This rule made sense in the 80s, but it doesn't match the modern world anymore. Why? The benefits to keep a system bootable and repairable is one of the reasons why unix systems are more robust or can better be repeaired than, lets say windows systems for example. I do not like the idea to throw away all those benefits just because so many (younger/newer) people do not know about the possibilities an old fashioned unix system tends to have. -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgpkTWMsEkKlm.pgp Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
2012/1/5 Ulrich Mueller u...@gentoo.org On Wed, 4 Jan 2012, Michał Górny wrote: There's really nothing pointless or blurry about this separation. The FHS has a nice definition: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Given that these tools are being moved to /usr and/or duplicated to in initrd , what is the point of a root filesystem anyway now? Just to mount other things on? Just to store /etc ? Or will /etc move to /usr too? /usr/etc somewhat horrifies me. And if you no longer have a suite of recovery tools on root, you *have* to really have a copy in initrd, otherwise when /usr gets damaged and needs repaired/recovered, you'll need a boot disk just to solve that problem. And that I don't fancy. And another errant thought: why not just repurpose the initrd as the root filesystem if the root filesystem is just to exist for the purpose of bolting other stuff on. Because in my mind, the primary benefit of initrd over an actual filesystem is the initrd is theoretically a lot harder to mess up, and you can easily have a plethora of alternative known-good initrd's to fall back on. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, 5 Jan 2012 07:27:49 +1300 Kent Fredric kentfred...@gmail.com wrote: 2012/1/5 Ulrich Mueller u...@gentoo.org On Wed, 4 Jan 2012, Michał Górny wrote: There's really nothing pointless or blurry about this separation. The FHS has a nice definition: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Given that these tools are being moved to /usr and/or duplicated to in initrd , what is the point of a root filesystem anyway now? Just to mount other things on? Just to store /etc ? Well, you can either keep both /etc and /usr on a single filesystem, or move /etc out of rootfs and just make it a tmpfs. And if you no longer have a suite of recovery tools on root, you *have* to really have a copy in initrd, otherwise when /usr gets damaged and needs repaired/recovered, you'll need a boot disk just to solve that problem. And that I don't fancy. And if / gets damaged, keeping those tools on / doesn't help either. If you have them on initramfs, they can fix it as well. Of course we could go onto 'what if initramfs gets damaged?' but then you're HDD got damaged as well... And another errant thought: why not just repurpose the initrd as the root filesystem if the root filesystem is just to exist for the purpose of bolting other stuff on. Noone forbids you to. But then you won't get your memory back when real system boots. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny schrieb: On Wed, 04 Jan 2012 13:06:11 +0100 Thomas Sachau to...@gentoo.org wrote: Michał Górny schrieb: On Wed, 04 Jan 2012 01:47:38 +0100 Thomas Sachau to...@gentoo.org wrote: 2. switching from udev to mdev (avoids required /usr of udev) 3. some wrapper script to mount /usr before udev starts These two should be really discouraged as a cheap, temporary solution. We should not support hate-admining. I personally think that busybox is ready to go into /usr even earlier than udev. Please give us a bit more than just your opinion. Why do you see mdev as a temporary solution? Because we will then return to this discussion at some later point and people will start throwing excrements at us again. So let's be done with this at once. Please tell me, how a replacement for udev, which in the end removes the requirement for mounted /usr at boot time, should later require a mounted /usr again. And please dont tell me, that this will happen because you moved everything to /usr. This is something you would like to do and wish to see, but i dont see it happen. And this part was not about the movement to /usr at all, so why do you suggest another movement here? And while you answer that, please also tell us, why you want to migrate packages to a different install location without a need. Because we need to finally be able to fix mistakes made in the past by other people. This has already been commented on by grobian and ulm, so i see no need to dublicate their lines. For the idea of complete migration to /usr, i see no reason to go this route in advance. Just keep with our default install locations and follow upstream, if and where needed. What about upstreams who do not care? In other words, all those packages which we hack to install into rootfs? They install and work fine, so just keep it this way. I did not see any argument to move packages around, that work well and have no issue with their current install location. What if, say, upstream introduces pkg-config file where our hacks will cause it to be installed into /lib/pkgconfig? Should we then expand the hack to cover that, and something else, and then another thing... Defining a prefix is no hack, it is an option you can use. Anyway, we both have probably enough packages with such a hack installed, but i cannot find a single file in /lib/pkgconfig, not even that dir does exist. Is it different on your system? If not, then please tell me, why you create some theory about possible issues, which dont even exist. Dont you have better arguments for your suggested move to /usr? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 4 Jan 2012 18:12:18 +0100 Ulrich Mueller u...@gentoo.org wrote: On Wed, 4 Jan 2012, Michał Górny wrote: What mistakes? The mistake of introducing a pointless separation based on a rule of thumb which becomes more and more blurry over time, and hacking packages just to make it work. There's really nothing pointless or blurry about this separation. The FHS has a nice definition: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Why don't we have sshd there then? I don't really feel like repairing remote system without fallback sshd. And a compiler. If I mess up some important system component, I'd really use one. And package manager. And backup system libraries... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, 2012-01-05 at 07:27 +1300, Kent Fredric wrote: 2012/1/5 Ulrich Mueller u...@gentoo.org On Wed, 4 Jan 2012, Michał Górny wrote: There's really nothing pointless or blurry about this separation. The FHS has a nice definition: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Given that these tools are being moved to /usr and/or duplicated to in initrd , what is the point of a root filesystem anyway now? Just to mount other things on? Just to store /etc ? Or will /etc move to /usr too? /usr/etc somewhat horrifies me. No no no, the idea is that once all binaries are in /usr, you can easily share /usr between different systems and do updates in a sane way.. You can also mount /usr read-only, but still have / be read-write. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 1:27 PM, Kent Fredric kentfred...@gmail.com wrote: Given that these tools are being moved to /usr and/or duplicated to in initrd , what is the point of a root filesystem anyway now? Just to mount other things on? Just to store /etc ? Or will /etc move to /usr too? I'd recommend reading the fedora docs. Their plan is to make /usr read-only so that it contains all elements of the system managed by the distro. In the future rpm world config files exist half on /usr, with overriding content in /etc (they don't have etc-update, and etc-update isn't always perfect either). But yes, the trend is towards making rootfs a bit more virtual. I can see some of the benefits of this arrangement, but by the time we get that all worked out btrfs might be practical, and its subvolumes actually solve many of the problems that lvm and many partitions are used to solve today. With btrfs you can make /usr a subvolume and snapshot it at will, or set up a quota just for it. That doesn't cover all the use cases, but it does cover most of the desktop-y ones. As far as repairing the system from rootfs goes - I think that greatly depends on your circumstances. If everything is on root anyway then it is a moot point. If everything isn't on root then your ability to recover is inversely proportional to the complexity of your systems. As others have pointed out, there is always something that you won't have, and to be honest it isn't all that hard to just boot a liveDVD that has everything and the kitchen sink available anyway. Rich
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 04-01-2012 19:50:24 +0100, Michał Górny wrote: On Wed, 4 Jan 2012 18:12:18 +0100 Ulrich Mueller u...@gentoo.org wrote: On Wed, 4 Jan 2012, Michał Górny wrote: What mistakes? The mistake of introducing a pointless separation based on a rule of thumb which becomes more and more blurry over time, and hacking packages just to make it work. There's really nothing pointless or blurry about this separation. The FHS has a nice definition: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Why don't we have sshd there then? I don't really feel like repairing remote system without fallback sshd. Network isn't typically in that bootlevel. You'd just attach through the console (netmgt, ipmi, keyboard/vga) instead. And a compiler. If I mess up some important system component, I'd really use one. And package manager. And backup system libraries... Time for your PXE boot from net to just bring back a sane image or so. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 04-01-2012 13:51:26 -0500, Olivier Crête wrote: No no no, the idea is that once all binaries are in /usr, you can easily share /usr between different systems and do updates in a sane way.. You can also mount /usr read-only, but still have / be read-write. http://article.gmane.org/gmane.linux.debian.devel.general/165891 -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 04 Jan 2012 19:48:03 +0100 Thomas Sachau to...@gentoo.org wrote: Defining a prefix is no hack, it is an option you can use. Anyway, we both have probably enough packages with such a hack installed, but i cannot find a single file in /lib/pkgconfig, not even that dir does exist. Is it different on your system? Defining a prefix is no hack. Defining a prefix would result in existence of such a file, and installation of static libraries in /lib. We use hacks to move shared libraries to rootfs, and then create one more hack to not confuse the linker with different locations of static and shared libraries. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 4 Jan 2012 20:00:51 +0100 Fabian Groffen grob...@gentoo.org wrote: On 04-01-2012 19:50:24 +0100, Michał Górny wrote: On Wed, 4 Jan 2012 18:12:18 +0100 Ulrich Mueller u...@gentoo.org wrote: On Wed, 4 Jan 2012, Michał Górny wrote: What mistakes? The mistake of introducing a pointless separation based on a rule of thumb which becomes more and more blurry over time, and hacking packages just to make it work. There's really nothing pointless or blurry about this separation. The FHS has a nice definition: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Why don't we have sshd there then? I don't really feel like repairing remote system without fallback sshd. Network isn't typically in that bootlevel. You'd just attach through the console (netmgt, ipmi, keyboard/vga) instead. And a compiler. If I mess up some important system component, I'd really use one. And package manager. And backup system libraries... Time for your PXE boot from net to just bring back a sane image or so. My PXE boot from net won't happen because possible /usr-over-NFS relies on random files from other rootfs, and they just failed to be in sync between two of my systems. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 04-01-2012 20:28:01 +0100, Michał Górny wrote: And a compiler. If I mess up some important system component, I'd really use one. And package manager. And backup system libraries... Time for your PXE boot from net to just bring back a sane image or so. My PXE boot from net won't happen because possible /usr-over-NFS relies on random files from other rootfs, and they just failed to be in sync between two of my systems. Seems like you've got a situation where you'd just shove in a livecd then. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 04-01-2012 20:26:27 +0100, Michał Górny wrote: We use hacks to move shared libraries to rootfs, and then create one more hack to not confuse the linker with different locations of static and shared libraries. So your point is that the reasons why this was originally done are now no longer valid, because...? -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 04, 2012 at 07:26:05PM +0100, Marc Schiffbauer wrote: For example, to make that FHS definition be reality there are (can be) runlevels that will only boot a system with all basic stuff required to mount the rootfs and make root being able to login to the local text console. These are the things that make a unixoid system valuable over other kind of systems. There are benefits to the proposed changes, especially for rpm based distros and especially for non-server settings. Are they good enough? No, I don't think they are. But since forking all those packages is not a realistic proposition, we will have to follow along. We should try and not break existing installations when we do though. I do not like the idea to throw away all those benefits just because so many (younger/newer) people do not know about the possibilities an old fashioned unix system tends to have. Hey, this is web 2.0 era. Being mostly right most of the time is good enough. -- Eray Aslan e...@gentoo.org signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 01/04/2012 09:32 AM, Olivier Crête wrote: On Wed, 2012-01-04 at 18:12 +0100, Ulrich Mueller wrote: On Wed, 4 Jan 2012, Michał Górny wrote: What mistakes? The mistake of introducing a pointless separation based on a rule of thumb which becomes more and more blurry over time, and hacking packages just to make it work. There's really nothing pointless or blurry about this separation. The FHS has a nice definition: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. The problem is that to boot a modern system, you need a shitload of stuff. For example, modern network filesystems often have secure authentication and probably LDAP too, so that means we need to move ldap and openssl into / and all the dependencies. Also, anything that installs a udev rule needs to be in /, and the list goes on an on. Very soon, you have almost everything in /... This rule made sense in the 80s, but it doesn't match the modern world anymore. Some longer explanations: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken https://fedoraproject.org/wiki/Features/UsrMove The FHS notion of root filesystem as a recovery partition existed long before the relatively modern development of things like busybox and initramfs made it more practical to use an initramfs as a recovery partition. Anyone who wouldn't prefer to use an initramfs for their recover partition probably just doesn't realize how well suited an initramfs is for the job. It's so well suited for the job that it makes the old FHS notion of root filesystem as a recovery partition seem quaint. -- Thanks, Zac
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 01 Jan 2012 16:49:42 -0500 Olivier Crête tes...@gentoo.org wrote: That's why you have dracut to do it for you. Which is keyworded at this point. Stable users do what? It's keyworded for only two arches. This is a discussion about the future... Changing keywords is trivial if we care. Oh, let's quickly drop the notion of arch testing/stabilisation. :) jer
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Jeroen Roovers wrote: On Sun, 01 Jan 2012 16:49:42 -0500 Olivier Crêtetes...@gentoo.org wrote: That's why you have dracut to do it for you. Which is keyworded at this point. Stable users do what? It's keyworded for only two arches. And amd64 is one of them. I'd say it is a fairly popular arch too. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote I see three options: 1) Start migrating packages along with upstream and have everyone who has a separate /usr (including me by the way) start using an initramfs of some kind, either dracut or one that we generate specifically for gentoo. The reason I suggest the initramfs, is, unfortunately if we migrate everything, nothing else would work. 2) Combine the sbin and bin directories both on the root filesystem and in /usr by moving things from /sbin to /bin and /usr/sbin to /usr/bin. 3) Try to maintain things the way they are as long as possible. 4) Following pointers from Zac Medico and others, I've managed to get Gentoo running with busybox's mdev, instead of udev. See http://archives.gentoo.org/gentoo-user/msg_bc91b392ee0f76376104591cdf7dc5f0.xml Executive summary... look Ma; no udev! In the instructions there, I've set up a revised dev-manager ebuild in an overlay. I've requested the changes to be incorporated into the official ebuild and it appears to have been accepted. See... https://bugs.gentoo.org/show_bug.cgi?id=395319 It should be rolled out eventually, and the overlay won't be necessary. I think I've found one item so far that requires udev. My laptop's graphics chip needs a binary blob from radeon-ucode. That binary blob, in turn, requires the presence of /usr/lib/libudev.so.0 which is a symlink to /usr/lib/libudev.so.0.9.3 (which is also required). I can emerge udev move or copy the 2 files over to /root unmerge udev move or copy the 2 files from /root to /usr/lib/ Note that /usr/lib/ is a symlink to /usr/lib64 on my 64-bit gentoo Please discuss; I want to hear what you think. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Hi Walter, On Tue, Jan 03, 2012 at 04:51:57AM -0500, Walter Dnes wrote: 4) Following pointers from Zac Medico and others, I've managed to get Gentoo running with busybox's mdev, instead of udev. See http://archives.gentoo.org/gentoo-user/msg_bc91b392ee0f76376104591cdf7dc5f0.xml Executive summary... look Ma; no udev! Unfortunately, it isn't going to be as simple as switching away from udev. This move is going to move all software from /bin, /sbin and /lib to /usr/bin and /usr/lib. The end result is going to be that regardless of whether you are using mdev or udev you will have to use an initramfs if /usr is on a separate partition. William pgpKPA7t5mMhB.pgp Description: PGP signature
