[gentoo-dev] Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
Kent Fredric posted on Thu, 15 Mar 2012 09:10:53 +1300 as excerpted: > On 15 March 2012 07:48, Duncan <1i5t5.dun...@cox.net> wrote: >> It does, especially when it's literally the case, including a /usr/etc >> bind-mounted on a tmpfs-based rootfs, that by login time, all that's >> visible of rootfs is mountpoints, nothing else, and /usr literally IS >> the "unified system resource" filesystem. > > Considering this pretty much eliminates using / for anything useful, > we might as well rename "/usr" "/c" > > Even if it /is/ just to confuse the windows crowd =) LOL! I've been off of MS over a decade now, and simply don't think of them that much any more. I had no clue what you were referencing... until I read that last line. You rather confused me! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 3/14/12 10:59 AM, Rich Freeman wrote: Well, anybody is welcome to create any replacement/addition for (/usr)/sbin/init or (/usr)/sbin/rc that they wish. If you make it good enough, perhaps others will even use it. There is a SoC out there for that. Beyond that, anything else is just a suggestion. In the end the folks writing udev and systemd are writing code, which gets them a lot further than emails do... :) People might be happy with what they have and might feel a bit threatened when they have to switch away from the DE they like because it forces on them an init system that they hate. lu
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 3/14/12 4:37 PM, Greg KH wrote: Not really, I don't think we support systems without udev anymore, right? And we get away with a lot of these different "options" at compile time, which makes it easier than what Debian has to handle, so perhaps it's not a fair comparison. I think we support systems with launchd and devd quite well and we'd love to support even some more. Sure, but that doesn't mean that the packages that are being merged will actually work :) Only if upstream really wants to break them... And that is the perceived situation, exacerbated by the past experience with a certain audio daemon trying to do too much at the same time. lu
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 3/14/12 10:58 AM, Matthew Summers wrote: __Everyone__ is already using an initramfs, therefore there are no initramfs-less systems anymore (it may just be empty). Every single person reading this thread that has not already done so needs to immediately go read the relevant documentation located in /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt, then and only then can a real discourse be had. Yawn, I don't and I won't since I don't need it. Why should I? Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite nice to have a minimal recovery env in case mounting fails, etc, etc, etc. Because at least for me is *totally* pointless. My main system is with a single partition so I shouldn't care much, I have a system that has a separate /usr so probably I'll have *some* pain once I'll upgrade it if I don't merge /usr and / partitions before. Still the whole idea brings us back to the freebsd "everything in /usr" while would make more sense go the hurd way "everything in /" if there is a sound reason to merge those. Beside the whole /usr/share/id-data-du-jour-my-udev-rule-might-need and the I-want-glib and I-want-dbus bandwagon I hadn't seen any compelling reason. Having anything as complex as dbus for early boot sounds dangerous or frail. lu
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 02:05 PM, Richard Yao wrote: > How did RedHat justify that lack of conformity that resulted from moving > everything into /usr in the first place? Does it really matter? What people in the separate-/usr-without-initramfs camp really want is continued support for the "/ is a self-contained boot disk that is independent of /usr" use case, because without such support, the separate-/usr-without-initramfs approach that they're accustomed to becomes impossible. The /usr merge [1] can be viewed as just one of many signs of a widespread shift away from supporting the heavy burden of the "/ is a self-contained boot disk that is independent of /usr" use case. [1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 21:06, Zac Medico wrote: > On 03/14/2012 05:58 PM, Richard Yao wrote: >> On 03/14/12 20:36, David Leverton wrote: >>> On 14 March 2012 23:47, Zac Medico wrote: It's more about what we're _not_ doing that what we're doing. >>> >>> Clearly something must have changed in udev 181 to make >>> /usr-without-initramfs not work anymore, and someone must have done >>> something to make that change happen, unless udev has aquired the >>> ability to evolve by itself. >>> >> >> I suggest that you file a bug report regarding this for the Gentoo udev >> maintainer. > > RESOLVED:UPSTREAM Lets permit the udev maintainer to do that. :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 21:07, Rich Freeman wrote: > On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao wrote: >> >> I proposed a way that this could work with no effort on the part of the >> Gentoo developers in one of my earlier emails: >> > > Then go ahead and make it happen. If as you say no dev participation > is needed there is nothing Gentoo needs to do to support this. That proposal was something that I had intended to abstract ebuild maintainers such as myself out of the picture. I am do not have a separate /usr filesystem, yet as an ebuild maintainer, I receive bug reports from those that do. If people want to guarentee that they can boot without an initramfs, they can implement my suggestion. If they don't, then it is no problem for me. I have already fixed things for the separate /usr crowd in my ebuilds. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 06:07 PM, Rich Freeman wrote: > For those who don't like the current direction, by all means create an > overlay called udev-root, mdev-boot, noinitramfs, or whatever. The simplest alternative to an initramfs that I can think of would be an init wrapper like the one that I suggested a while back [1]. [1] http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao wrote: > > I proposed a way that this could work with no effort on the part of the > Gentoo developers in one of my earlier emails: > Then go ahead and make it happen. If as you say no dev participation is needed there is nothing Gentoo needs to do to support this. On Wed, Mar 14, 2012 at 6:49 PM, Greg KH wrote: > > We aren't Debian here people, we don't support "everything" :) > > If you want to support both, great, feel free to step up and do the > work. > Gentoo is about choice, but it is largely about the choices that people are willing to step up and maintain. A few months ago there was a big thread and lots of devs said that systemd isn't supported on Gentoo. Some devs stepped up and decided to maintain it and now I'd say systemd is about as supported on Gentoo as Prefix, FreeBSD, Sparc, or MIPS. That didn't happen because of mailing list persuasion - it happened because a few people interested in making it happen wrote a bunch of ebuilds. How do systemd units end up in various packages? The people interested in seeing them write good-quality patches and submit bugs, or otherwise work with the maintainers to commit them. For those who don't like the current direction, by all means create an overlay called udev-root, mdev-boot, noinitramfs, or whatever. You don't need anybody's permission to do it - just go on github and make it happen. Write some good code. There are several devs here who might even help you out with it, and nobody here is going to object to packages going into the main tree as long as they're maintained in accordance with Gentoo QA. Create some USE flags where you need tie-ins to other system packages and as long as everything behaves nicely and patches are good and maintained, I'm sure the package maintainers will accept them. Gentoo already gives its users a lot of choice, but it can only offer the choices that people are willing to maintain. Right now I see a lot of complaining and not a lot of maintaining. When I see a package lastrited I don't moan about it - I either sigh or sign up to maintain it. By all means make suggestions to improve the transition or write docs, but simply posting on this list isn't likely to change the direction the linux winds are blowing. The forces involved are much larger than Gentoo. Rich
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 05:58 PM, Richard Yao wrote: > On 03/14/12 20:36, David Leverton wrote: >> On 14 March 2012 23:47, Zac Medico wrote: >>> It's more about what we're _not_ doing that what we're doing. >> >> Clearly something must have changed in udev 181 to make >> /usr-without-initramfs not work anymore, and someone must have done >> something to make that change happen, unless udev has aquired the >> ability to evolve by itself. >> > > I suggest that you file a bug report regarding this for the Gentoo udev > maintainer. RESOLVED:UPSTREAM -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 20:36, David Leverton wrote: > On 14 March 2012 23:47, Zac Medico wrote: >> It's more about what we're _not_ doing that what we're doing. > > Clearly something must have changed in udev 181 to make > /usr-without-initramfs not work anymore, and someone must have done > something to make that change happen, unless udev has aquired the > ability to evolve by itself. > I suggest that you file a bug report regarding this for the Gentoo udev maintainer. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 15 March 2012 00:45, Zac Medico wrote: > You're pointing your finger at udev, but the udev change is just a > symptom of a more general shift away from supporting the "/ is a > self-contained boot disk that is independent of /usr" use case. OK, so there are multiple instances of people not not doing anything rather than just one. I think that supports my point more than it refutes it.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 05:36 PM, David Leverton wrote: > On 14 March 2012 23:47, Zac Medico wrote: >> It's more about what we're _not_ doing that what we're doing. > > Clearly something must have changed in udev 181 to make > /usr-without-initramfs not work anymore, and someone must have done > something to make that change happen, unless udev has aquired the > ability to evolve by itself. You're pointing your finger at udev, but the udev change is just a symptom of a more general shift away from supporting the "/ is a self-contained boot disk that is independent of /usr" use case. -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 23:47, Zac Medico wrote: > It's more about what we're _not_ doing that what we're doing. Clearly something must have changed in udev 181 to make /usr-without-initramfs not work anymore, and someone must have done something to make that change happen, unless udev has aquired the ability to evolve by itself.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 23:44, Greg KH wrote: > Oh, and somehow "consensus" will work? No, sorry, it will not. No, logical analysis will, as I said in the rest of my post which you conveniently ignored - either we conclude with evidence that there are no issues, which should settle the matter for reasonable people, or we discover that there are, in which case they have to be dealt with one way or another. I really don't see how anyone can object to that, unless they're worried they won't like the result > How about the basic FACT that today, such systems do not work This is debatable at best. You can keep screaming "but bluetooth won't work!" until you're blue in the face, but that's not relevant at all to people who don't use bluetooth. > and are not supported by a wide range of packages we support today. Isn't such support being removed by the same people who keep arguing that it's already not supported? That's like cutting half your employees' pay, and then insisting that you have to choice but to cut the other half's pay as well, in order to be fair. > Yes, some people are "lucky" in that their systems don't have those > packages, but others are not. The simple "I use a bluetooth keyboard" > is one such example. People who only have a bluetooth keyboard can set their systems up in such a way that it works, just like how people who have / on lvm can set their systems up in such a way that that works. That's not in itself a reason to force it on everyone. > It is strange to watch people somehow think that if they complain > enough, or feel strongly enough, something is going to change here to > make this basic fact go away. If by "the basic fact" you mean that plenty of people are quite happy doing what's worked just fine for years, then yes.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 07:58:23PM -0400, Richard Yao wrote: > On 03/14/12 19:44, Greg KH wrote: > > Now, to get back to what I said before, I'm done with this thread, it's > > going nowhere, and it seems I'm just making it worse, my apologies. For > > penance, I'll adopt the next abandoned package someone throws at me, any > > suggestions? > > Bug #360513 needs work. Something in sys-boot/grub-0.97-r* is triggering > a bug in the GNU toolchain. Few of us have time to deal with it, so it > would be much appreciated if you would take care of it. ;) grub is not an abandoned package, it's as if people don't read what I write...
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 19:44, Greg KH wrote: > Now, to get back to what I said before, I'm done with this thread, it's > going nowhere, and it seems I'm just making it worse, my apologies. For > penance, I'll adopt the next abandoned package someone throws at me, any > suggestions? Bug #360513 needs work. Something in sys-boot/grub-0.97-r* is triggering a bug in the GNU toolchain. Few of us have time to deal with it, so it would be much appreciated if you would take care of it. ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 19:37, Greg KH wrote:
>> Portage provides use with the ability to do abstractions that other
>> distributions cannot do, such as permitting people to merge
>> /usr{bin,lib{32,64,},sbin} into /.
>
> Sure, but that doesn't mean that the packages that are being merged will
> actually work :)
>
> greg k-h
I proposed a way that this could work with no effort on the part of the
Gentoo developers in one of my earlier emails:
On 03/14/12 17:05, Richard Yao wrote:
> In the meantime, it should be possible to create a global usr USE flag
> that enables/disables gen_usr_ldscript. It would then be possible to
> delete all of the usr ldscripts, dump /usr into / and symlink /usr to /.
> The dynamic linker would go to / before /usr and it would be trivial to
> modify $PATH to ignore /usr entirely. Legacy software that requires
> /usr/{bin,sbin} would still work while those that want a separate /usr
> mount could symlink /usr/{bin,include,libexec,sbin} into their rootfs
> counterparts.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 04:21 PM, David Leverton wrote: > On 14 March 2012 22:51, Greg KH wrote: >> Oh, that's simple, separate-/usr-without-initramfs will not work and >> will not be supported :) > > See, it's this "we're doing it this way because we know best and we > say so" that upsets people. It's more about what we're _not_ doing that what we're doing. What we're not doing is supporting the "/ is a self-contained boot disk that is independent of /usr" use case, simply because it's a huge maintenance burden and it doesn't make much sense in the post-initramfs world. The people who have a "problem" with this don't understand the burden and have no intention of taking on the burden themselves. Even if they wanted to take on the burden, they wouldn't be capable of it. If they were capable of taking on this burden then they would have already understood that the initramfs is the most reasonable solution to their perceived problem. -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 11:21:44PM +, David Leverton wrote: > On 14 March 2012 22:51, Greg KH wrote: > > Oh, that's simple, separate-/usr-without-initramfs will not work and > > will not be supported :) > > See, it's this "we're doing it this way because we know best and we > say so" that upsets people. Oh, and somehow "consensus" will work? No, sorry, it will not. How about the basic FACT that today, such systems do not work, and are not supported by a wide range of packages we support today. Yes, some people are "lucky" in that their systems don't have those packages, but others are not. The simple "I use a bluetooth keyboard" is one such example. So it's not a "we know best", it's a "it will not properly work otherwise." It is strange to watch people somehow think that if they complain enough, or feel strongly enough, something is going to change here to make this basic fact go away. Now, to get back to what I said before, I'm done with this thread, it's going nowhere, and it seems I'm just making it worse, my apologies. For penance, I'll adopt the next abandoned package someone throws at me, any suggestions? greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 07:27:07PM -0400, Richard Yao wrote:
> >> 3. Why not let the users choose where these directories go and support
> >> both locations?
> >
> > Because a plethera of options is a sure way to make sure that half of
> > them don't work over the long run.
> >
> > We aren't Debian here people, we don't support "everything" :)
>
> Gentoo provides far more options than Debian does, so this seems
> somewhat contradictory to me.
Not really, I don't think we support systems without udev anymore,
right? And we get away with a lot of these different "options" at
compile time, which makes it easier than what Debian has to handle, so
perhaps it's not a fair comparison.
> > If you want to support both, great, feel free to step up and do the
> > work.
>
> Fair enough, however, I should remind you that not much will happen
> without a decision from the Gentoo Council. I am willing to accept
> whatever decision they make, but I think that exposing this decision to
> users is something that is within our ability to do.
I didn't think the Council ruled on technical questions.
In fact, how is this relevant at all anyway? It's quite simple in that
we don't support systems today with a separate /usr/ without a
initramfs/initrd. If it happens to work, wonderful, but don't expect
Gentoo developers to rewrite the upstream packages to work for this type
of unsupported systems, it's not going to happen.
Or are you referring to the "no more /bin and /sbin" thing? That's just
going to happen "naturally", one day in a few months or years, your
system will have moved to this without you even realizing it :)
> Portage provides use with the ability to do abstractions that other
> distributions cannot do, such as permitting people to merge
> /usr{bin,lib{32,64,},sbin} into /.
Sure, but that doesn't mean that the packages that are being merged will
actually work :)
greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 18:49, Greg KH wrote:
> On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote:
>> With that said, I have a few questions:
>>
>> 1. Why does no one mention the enterprise use case at all?
>
> It has been pointed out before, why constantly repeat ourselves.
Simple. No one has documented it. A webpage that makes a few vague
references to "enterprise use" does not count as documentation.
I happened to figure it out when trying to rationalize why anyone would
want this, but this is hardly obvious to those that imagine a computer
as a self-sufficient single disk system.
>> 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device?
>
> unionfs is still a "work in progress", some systems can't do that yet.
That sounds like something that needs to be fixed.
>> 3. Why not let the users choose where these directories go and support
>> both locations?
>
> Because a plethera of options is a sure way to make sure that half of
> them don't work over the long run.
>
> We aren't Debian here people, we don't support "everything" :)
Gentoo provides far more options than Debian does, so this seems
somewhat contradictory to me.
> If you want to support both, great, feel free to step up and do the
> work.
Fair enough, however, I should remind you that not much will happen
without a decision from the Gentoo Council. I am willing to accept
whatever decision they make, but I think that exposing this decision to
users is something that is within our ability to do.
Portage provides use with the ability to do abstractions that other
distributions cannot do, such as permitting people to merge
/usr{bin,lib{32,64,},sbin} into /.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 22:51, Greg KH wrote: > Oh, that's simple, separate-/usr-without-initramfs will not work and > will not be supported :) See, it's this "we're doing it this way because we know best and we say so" that upsets people. I'm trying to encourage everyone to get to the core reasons for having a separate /usr in the first place (not all of which are guaranteed to be mentioned on any specific wiki page), and logically analyse the potential disadvantages of using an initramfs in each situation. It may turn out that there are no disadvantages after all, but the analysis is still important, not only to make sure that "we"'re making the right decision, but also to persuade everyone else that it's the right decision. > Again, the fact that it works for some people today is pure luck, and > odds are, it really isn't, but it's really hard to determine this given > that the init system they are using doesn't provide a good feedback loop > for this type of thing. Maybe it would be worth improving the init system to do so? Or maybe it wouldn't because using an initramfs is easier and has no drawbacks, but see above.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 10:14:54PM +, David Leverton wrote: > On 14 March 2012 21:04, Greg KH wrote: > > Haveing a separate /usr is wonderful, and once we finish moving /sbin/ > > and /bin/ into /usr/ it makes even more sense. See the /usr page at > > fedora for all of the great reasons why this is good. > > My point was examine, in detail, whether separate-/usr-with-initramfs > has any disadvantages compared to separate-/usr-without-initramfs. Oh, that's simple, separate-/usr-without-initramfs will not work and will not be supported :) Again, the fact that it works for some people today is pure luck, and odds are, it really isn't, but it's really hard to determine this given that the init system they are using doesn't provide a good feedback loop for this type of thing. Hence, it is not supported. thanks, greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote: > Is this that page? > > http://fedoraproject.org/wiki/Features/UsrMove > > That refers to the systemd website on freedesktop.org. > > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge Yes. > With that said, I have a few questions: > > 1. Why does no one mention the enterprise use case at all? It has been pointed out before, why constantly repeat ourselves. > 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device? unionfs is still a "work in progress", some systems can't do that yet. > 3. Why not let the users choose where these directories go and support > both locations? Because a plethera of options is a sure way to make sure that half of them don't work over the long run. We aren't Debian here people, we don't support "everything" :) If you want to support both, great, feel free to step up and do the work. greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 17:04, Greg KH wrote: > On Wed, Mar 14, 2012 at 07:57:52PM +, David Leverton wrote: >> Would anyone else like to continue with their own favourite >> separate-/usr reason? > > Haveing a separate /usr is wonderful, and once we finish moving /sbin/ > and /bin/ into /usr/ it makes even more sense. See the /usr page at > fedora for all of the great reasons why this is good. > > What doesn't make sense is people who do that, refusing to use an initrd > or initramfs to make the whole thing work properly. > > It's as if people want the benefits, yet fail to want to actually use > the tools required to get those benefits. It makes no sense, and if > anyone continues to complain, it shows a lack of understanding. > > greg k-h > Is this that page? http://fedoraproject.org/wiki/Features/UsrMove That refers to the systemd website on freedesktop.org. http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge Reading that, it seems to me that this /usr move was caused by a systemd-specific decision that rootfs should be both system-specific and located on the particular system while /usr should be network mountable. However, I see no argument for why that should be the case. Thinking about it, I suppose this would make sense in an enterprise setting where everything is diskless. If you PXE boot, put rootfs on iSCSI and have /usr on a NFS mount, this would work very well. Claiming that people show a lack of understanding when you never explain this, however, is definitely the wrong thing to do. With that said, I have a few questions: 1. Why does no one mention the enterprise use case at all? 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device? 3. Why not let the users choose where these directories go and support both locations? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 21:04, Greg KH wrote: > Haveing a separate /usr is wonderful, and once we finish moving /sbin/ > and /bin/ into /usr/ it makes even more sense. See the /usr page at > fedora for all of the great reasons why this is good. My point was examine, in detail, whether separate-/usr-with-initramfs has any disadvantages compared to separate-/usr-without-initramfs. Either it has, in which case we have a concrete argument against requiring initramfs (albeit possibly one that can be fixed), or it hasn't, which should hopefully convince at least some people to accept it.
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Wed, Mar 14, 2012 at 08:07:07AM -0400, Joshua Kinard wrote > Ah, bluetooth keyboards. The luddite in me finds those quite > the oddity. I still use only PS/2, specifically because it's less > complex and less likely to fail on me in a time of need. Unicomp has licenced manufacturing rights to the IBM Model M keyboard, with USB adapter, of course. http://pckeyboard.com/page/product/UNI041A Look Ma, no Windows keys! If you do want Windows keys, you can order http://pckeyboard.com/page/product/UNI0P4A And if you want an original with PS/2 connector, they also offer http://pckeyboard.com/page/category/IBMKBD -- Walter Dnes
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 16:55, Zac Medico wrote:
> On 03/14/2012 01:03 PM, Richard Yao wrote:
>> I do not have a separate /usr partition, however I agree with Joshua
>> Kinard's stance regarding the /usr move. The point of having a separate
>> /usr was to enable UNIX to exceed the space constraints that a 1.5MB
>> hard disk placed on rootfs. As far as I know, we do not support a 1.5MB
>> rootfs so it would make sense to deprecate the practice of having things
>> that belong in / in /usr directory, as opposed to making /usr into a new /.
>>
>> Deprecation of this practice would mean that people could type
>> /bin/command instead of /usr/bin/command in situations where absolute
>> paths are necessary. We could symlink things in /usr to rootfs for
>> compatibility with legacy software. In a more extreme case, we could
>> symlink /usr to /, which would make plenty of sense given that we do not
>> need a separate /usr at all.
>
> I'm not seeing any compelling benefits here that would justify a lack of
> conformity with other *nix distros. It seems almost as though it's an
> attempt to be different for the sake of being different, perhaps a
> symptom of something like NIH syndrome.
How did RedHat justify that lack of conformity that resulted from moving
everything into /usr in the first place? The original UNIX did not have
anything in /usr. The /usr split was caused by Bell Labs having to grow
UNIX past the constraints of a 1.5MB hard drive. Since we are no longer
limited by such space constraints, I fail to see why we should not
deprecate /usr.
In the meantime, it should be possible to create a global usr USE flag
that enables/disables gen_usr_ldscript. It would then be possible to
delete all of the usr ldscripts, dump /usr into / and symlink /usr to /.
The dynamic linker would go to / before /usr and it would be trivial to
modify $PATH to ignore /usr entirely. Legacy software that requires
/usr/{bin,sbin} would still work while those that want a separate /usr
mount could symlink /usr/{bin,include,libexec,sbin} into their rootfs
counterparts.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 07:57:52PM +, David Leverton wrote: > Would anyone else like to continue with their own favourite > separate-/usr reason? Haveing a separate /usr is wonderful, and once we finish moving /sbin/ and /bin/ into /usr/ it makes even more sense. See the /usr page at fedora for all of the great reasons why this is good. What doesn't make sense is people who do that, refusing to use an initrd or initramfs to make the whole thing work properly. It's as if people want the benefits, yet fail to want to actually use the tools required to get those benefits. It makes no sense, and if anyone continues to complain, it shows a lack of understanding. greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 03:59:56PM +, Ciaran McCreesh wrote: > On Wed, 14 Mar 2012 08:22:09 -0700 > Greg KH wrote: > > The people doing the work today do understand them, by virtue of > > doing the work involved, which gives them the say in how it is done. > > That's how open source works, why is this ever a surprise to people? > > The problem is that when a small number of people who have commit > access to core projects screw everything up and don't fix the mess > they're inflicting upon everyone, Again, there is a simple solution for this problem, already provided, and supported, so no "mess" talking here please, that's just trying to be dramatic. > the only option left with "how open source works" is for someone to > fork the code from the point where it all worked. That isn't something > that should be done lightly. Forking should ALWAYS be done lightly and often, I highly recommend it. If you think you know how to do something better, it's best to fork, work it out, and if you come up with something, then work to merge it back, if at all possible. If merging doesn't work, and it turns out that your stuff works better, people will migrate to it, keeping it alive. Odds are, the fork will turn out to be a dead-end, and it will die off. But you will then know the reasons why, and not be so upset when others do things you disagree with. That's the way evolution works, and it works quite well, it's why open soure works as well as it does. So please, fork away, I can't recommend it enough. Remember, it's what got us Gentoo :) greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 01:03 PM, Richard Yao wrote: > On 03/14/12 14:56, Zac Medico wrote: >> On 03/14/2012 11:36 AM, Maxim Kammerer wrote: >>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers >>> wrote: Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite nice to have a minimal recovery env in case mounting fails, etc, etc, etc. >>> >>> There is nothing bad about initramfs. I think that you are misreading >>> the arguments above. >> >> Whatever the arguments may be, the whole discussion boils down to the >> fact that the only people who seem to have a "problem" are those that >> have a separate /usr partition and simultaneously refuse to use an >> initramfs. > > I do not have a separate /usr partition, however I agree with Joshua > Kinard's stance regarding the /usr move. The point of having a separate > /usr was to enable UNIX to exceed the space constraints that a 1.5MB > hard disk placed on rootfs. As far as I know, we do not support a 1.5MB > rootfs so it would make sense to deprecate the practice of having things > that belong in / in /usr directory, as opposed to making /usr into a new /. > > Deprecation of this practice would mean that people could type > /bin/command instead of /usr/bin/command in situations where absolute > paths are necessary. We could symlink things in /usr to rootfs for > compatibility with legacy software. In a more extreme case, we could > symlink /usr to /, which would make plenty of sense given that we do not > need a separate /usr at all. I'm not seeing any compelling benefits here that would justify a lack of conformity with other *nix distros. It seems almost as though it's an attempt to be different for the sake of being different, perhaps a symptom of something like NIH syndrome. -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 08:04:31AM -0700, Greg KH wrote > On Wed, Mar 14, 2012 at 10:51:44AM -0400, Philip Webb wrote: > > 120314 Greg KH wrote: > > > if you have /usr on a different filesystem today, with no initrd, > > > your machine could be broken and you don't even know it. > > > > Whatever do you mean ? -- if it were truly broken, > > it wouldn't perform in some important & obvious respect. > > Not always, no, it isn't obvious that something didn't start up > correctly, or that it didn't fully load properly. Some programs later > on recover and handle things better. Throwing that one right back at you, if you have /usr on the same file system, plus you boot with systemd, your machine could be broken and you don't even know it. -- Walter Dnes
Re: [gentoo-dev] Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 15 March 2012 07:48, Duncan <1i5t5.dun...@cox.net> wrote: > It does, especially when it's literally the case, including a /usr/etc > bind-mounted on a tmpfs-based rootfs, that by login time, all that's > visible of rootfs is mountpoints, nothing else, and /usr literally IS the > "unified system resource" filesystem. Considering this pretty much eliminates using / for anything useful, we might as well rename "/usr" "/c" Even if it /is/ just to confuse the windows crowd =) -- 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] Re: Let's redesign the entire filesystem!
On 03/14/12 14:56, Zac Medico wrote: > On 03/14/2012 11:36 AM, Maxim Kammerer wrote: >> On Wed, Mar 14, 2012 at 19:58, Matthew Summers >> wrote: >>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite >>> nice to have a minimal recovery env in case mounting fails, etc, etc, >>> etc. >> >> There is nothing bad about initramfs. I think that you are misreading >> the arguments above. > > Whatever the arguments may be, the whole discussion boils down to the > fact that the only people who seem to have a "problem" are those that > have a separate /usr partition and simultaneously refuse to use an > initramfs. I do not have a separate /usr partition, however I agree with Joshua Kinard's stance regarding the /usr move. The point of having a separate /usr was to enable UNIX to exceed the space constraints that a 1.5MB hard disk placed on rootfs. As far as I know, we do not support a 1.5MB rootfs so it would make sense to deprecate the practice of having things that belong in / in /usr directory, as opposed to making /usr into a new /. Deprecation of this practice would mean that people could type /bin/command instead of /usr/bin/command in situations where absolute paths are necessary. We could symlink things in /usr to rootfs for compatibility with legacy software. In a more extreme case, we could symlink /usr to /, which would make plenty of sense given that we do not need a separate /usr at all. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 18:56, Zac Medico wrote: > Whatever the arguments may be, the whole discussion boils down to the > fact that the only people who seem to have a "problem" are those that > have a separate /usr partition and simultaneously refuse to use an > initramfs. I wonder if it might help to go through the benefits of having a separate /usr, and see whether they still work when /usr is mounted by initramfs. Hopefully that would either demonstrate that the initramfs approach is fine, or reveal a concrete problem with it so we can start talking about solutions. (For the record, I don't have a separate /usr, but mainly because when I've been setting up machines I've been too lazy to either 1) figure out how much space to allocate to each partition, or 2) learn how to use lvm so I don't have to worry so much about getting it right the first time. I'd prefer for the option to stay available, but not as strongly as some people do.) To start us off, the benefit that I'm mainly interested in (for potential future use, as stated above), and I realise this is probably pretty far down the list overall, is that OpenRC can run fsck at shutdown instead of boot for non-/ filesystems, so as long as / is small there won't be huge boot delays. I imagine using initramfs wouldn't affect this, as by the time the system's shutting down it shouldn't matter how /usr got mounted originally. It might be affected if fsck etc got moved to /usr as has been mentioned, but if that happened OpenRC would probably have to be modified to remount it readonly at shutdown rather than unmount it, and presumably that would allow the fsck to occur. Would anyone else like to continue with their own favourite separate-/usr reason?
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, 14 Mar 2012 12:58:26 -0500 Matthew Summers wrote: > __Everyone__ is already using an initramfs, therefore there are no > initramfs-less systems anymore (it may just be empty). I happen to understand you're not attempting to start a flame war here, but it may not obvious to everyone. jer (no initrds)
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 12:14 PM, Michael Orlitzky wrote: > On 03/14/12 14:56, Zac Medico wrote: >> On 03/14/2012 11:36 AM, Maxim Kammerer wrote: >>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers >>> wrote: Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite nice to have a minimal recovery env in case mounting fails, etc, etc, etc. >>> >>> There is nothing bad about initramfs. I think that you are misreading >>> the arguments above. >> >> Whatever the arguments may be, the whole discussion boils down to the >> fact that the only people who seem to have a "problem" are those that >> have a separate /usr partition and simultaneously refuse to use an >> initramfs. > > People just don't like change for the sake of change, and haven't been > shown any benefits yet. I don't have a separate /usr anywhere, but if I > did, I would have to rebuild and test a good number of custom kernels > that would eventually need to wind up on production servers. > > It would take a least a day's worth of work, not to mention staying late > to make the switch overnight. If you can offer me something cool for it, > great; but at the moment people are being offered "it will work the same > as it did yesterday," which sucks, because it works that way now. > > Sure, there will be improvements in the future, but it can feel a lot > like treading water sometimes. Well, for most people, the most practical course of action is to suck it up [1] and move on. Dwelling on it certainly won't help, and the "redesign the entire filesystem" approach probably isn't very practical for most people either. [1] http://en.wiktionary.org/wiki/suck_it_up -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 14:56, Zac Medico wrote: > On 03/14/2012 11:36 AM, Maxim Kammerer wrote: >> On Wed, Mar 14, 2012 at 19:58, Matthew Summers >> wrote: >>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite >>> nice to have a minimal recovery env in case mounting fails, etc, etc, >>> etc. >> >> There is nothing bad about initramfs. I think that you are misreading >> the arguments above. > > Whatever the arguments may be, the whole discussion boils down to the > fact that the only people who seem to have a "problem" are those that > have a separate /usr partition and simultaneously refuse to use an > initramfs. People just don't like change for the sake of change, and haven't been shown any benefits yet. I don't have a separate /usr anywhere, but if I did, I would have to rebuild and test a good number of custom kernels that would eventually need to wind up on production servers. It would take a least a day's worth of work, not to mention staying late to make the switch overnight. If you can offer me something cool for it, great; but at the moment people are being offered "it will work the same as it did yesterday," which sucks, because it works that way now. Sure, there will be improvements in the future, but it can feel a lot like treading water sometimes.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 11:36 AM, Maxim Kammerer wrote: > On Wed, Mar 14, 2012 at 19:58, Matthew Summers > wrote: >> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite >> nice to have a minimal recovery env in case mounting fails, etc, etc, >> etc. > > There is nothing bad about initramfs. I think that you are misreading > the arguments above. Whatever the arguments may be, the whole discussion boils down to the fact that the only people who seem to have a "problem" are those that have a separate /usr partition and simultaneously refuse to use an initramfs. -- Thanks, Zac
[gentoo-dev] Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
Zac Medico posted on Wed, 14 Mar 2012 10:52:48 -0700 as excerpted: > On 03/14/2012 05:00 AM, James Cloos wrote: >>> "MS" == Marc Schiffbauer writes: >> >> MS> IIRC usr = unified system resources (not an abbrev. for "user") >> Before sysv created /home, bsd used /usr for user dirs. > Anyway, "unified system resources" makes a great retro-active acronym, > don't you think? What's in a name? It does, especially when it's literally the case, including a /usr/etc bind-mounted on a tmpfs-based rootfs, that by login time, all that's visible of rootfs is mountpoints, nothing else, and /usr literally IS the "unified system resource" filesystem. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: newsitem: unmasking udev-181
Joshua Kinard posted on Wed, 14 Mar 2012 08:07:07 -0400 as excerpted: > Ah, bluetooth keyboards. The luddite in me finds those quite the > oddity. > I still use only PS/2, specifically because it's less complex and less > likely to fail on me in a time of need. > > Or, put more comically: > http://megatokyo.com/strip/305 I was in that group for a long time, myself, but eventually graduated to a usb keyboard when I realized that the usb/wireless adapter I was using for combined mouse/keyboard, only needed one plug when it was using usb, two when using ps/2, and I was switching it around between computers. So usb's the one I have setup in both BIOS and the kernel, now. bluez keyboards require userspace, tho, I believe, thus the early-boot factor we're discussing. If I had a choice I'd avoid that, just as you. But some folks don't have that choice, or if they do it's between that and a touchscreen, also requiring userspace. I think rich0 is correct in viewing it as simply adding a few special- casing scripts to the kernel tarball (initramfs), tho, adding to the already special-case asm and the bootloader requirements... It's not exactly pleasant to have to adapt, but at least most of the linux world will eventually take it for granted. Well, probably most already does, but now it's getting even MORE required. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 19:58, Matthew Summers wrote: > __Everyone__ is already using an initramfs, therefore there are no > initramfs-less systems anymore (it may just be empty). I suggest that you take a look at CONFIG_BLK_DEV_INITRD. > Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite > nice to have a minimal recovery env in case mounting fails, etc, etc, > etc. There is nothing bad about initramfs. I think that you are misreading the arguments above. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, 14 Mar 2012 12:58:26 -0500 Matthew Summers wrote: > Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite > nice to have a minimal recovery env in case mounting fails, etc, etc, > etc. Because the initramfs is just replacing what / used to be, and it's even less well handled than "stuff not in /usr" is just now. All using an initramfs does is move the dependencies problem from somewhere where we have a solution that used to work and that still mostly works to somewhere where we don't have anything at all. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 1:29 PM, Zac Medico wrote: > On 03/14/2012 10:11 AM, Maxim Kammerer wrote: >> What's wrong with: >> * having an "early mounts" list file >> * having an "early modules" list file >> * init system in early boot (e.g., OpenRC in init.sh) loading "early >> modules" and mounting "early mounts" from /etc/fstab > > You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init. > Other that that, it sounds like a perfect solution if you're in the "I'd > rather die than use an initramfs" camp. Well, anybody is welcome to create any replacement/addition for (/usr)/sbin/init or (/usr)/sbin/rc that they wish. If you make it good enough, perhaps others will even use it. Beyond that, anything else is just a suggestion. In the end the folks writing udev and systemd are writing code, which gets them a lot further than emails do... :) Rich
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 12:29 PM, Zac Medico wrote: > On 03/14/2012 10:11 AM, Maxim Kammerer wrote: >> What's wrong with: >> * having an "early mounts" list file >> * having an "early modules" list file >> * init system in early boot (e.g., OpenRC in init.sh) loading "early >> modules" and mounting "early mounts" from /etc/fstab > > You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init. > Other that that, it sounds like a perfect solution if you're in the "I'd > rather die than use an initramfs" camp. > -- > Thanks, > Zac > __Everyone__ is already using an initramfs, therefore there are no initramfs-less systems anymore (it may just be empty). Every single person reading this thread that has not already done so needs to immediately go read the relevant documentation located in /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt, then and only then can a real discourse be had. Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite nice to have a minimal recovery env in case mounting fails, etc, etc, etc. :/ -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 03/14/2012 05:00 AM, James Cloos wrote: >> "MS" == Marc Schiffbauer writes: > > MS> IIRC usr = unified system resources (not an abbrev. for "user") > > Nope. It is in fact for user. > > Before sysv created /home, bsd used /usr for user dirs. > > /usr/bin et all came later. Anyway, "unified system resources" makes a great retro-active acronym, don't you think? What's in a name? -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 10:11 AM, Maxim Kammerer wrote: > What's wrong with: > * having an "early mounts" list file > * having an "early modules" list file > * init system in early boot (e.g., OpenRC in init.sh) loading "early > modules" and mounting "early mounts" from /etc/fstab You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init. Other that that, it sounds like a perfect solution if you're in the "I'd rather die than use an initramfs" camp. -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 17:22, Greg KH wrote: > As for "fixing this", see the oft-linked webpage as to why it can't be > fixed easily, if at all, and honestly, I don't think it needs to be > fixed. What's wrong with: * having an "early mounts" list file * having an "early modules" list file * init system in early boot (e.g., OpenRC in init.sh) loading "early modules" and mounting "early mounts" from /etc/fstab This will solve the issue with most non-complex (i.e., no raid or encryption) initramfs-less setups, without requiring that users migrate to initramfs (e.g., after dealing with genkernel-generated scripts for a long time, I wouldn't touch it with a pointed stick anymore). The relevant files can be also generated automatically during an upgrade (empty "early modules" and empty or /usr-only "early mounts", depending on /etc/fstab contents). -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 10:22 AM, Greg KH wrote: > On Wed, Mar 14, 2012 at 03:08:27PM +, Ciaran McCreesh wrote: >> On Wed, 14 Mar 2012 08:04:31 -0700 >> Greg KH wrote: >> > Not always, no, it isn't obvious that something didn't start up >> > correctly, or that it didn't fully load properly. Some programs later >> > on recover and handle things better. >> >> So why not work on fixing those things, since they're clearly symptoms >> of a larger "oops, we have too much coupling" problem, instead of >> forcing a workaround onto large numbers of users? > > I seriously doubt there are a "large number" of users here that have > this issue. > The majority of users should not encounter any difficulty due to this issue. Those that are doing special things that require careful mounting, etc should be sufficiently competent to deal with this issue without any trouble at all, especially given the various solution paths. > And even if there is, again, there is a simple solution that Gentoo > provides for this issue, see the earlier initrd solution that we support > today. > Gentoo provides a solution with genkernel, dracut provides a solution, even the linux kernel itself provides a solution (in my view the easiest solution at that). > I'll go back to lurking now, and getting stuff done, like everyone else > on this thread should be doing, instead of complaining (this is -dev, > not -users...) > > greg k-h > Oh, please Greg, do continue to stay engaged, I enjoy your perspective very much. I just wanted to drop this simple fact in there. This has been coming for several years now AND the linux kernel has been using an initramfs for every boot, every time for a long time now, all 2.6 and up as I understand it. If the initramfs is empty, well the kernel is smart enough to fall back on "legacy" boot process. If you care to read about it, its all contained locally if your kernel source in the file linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt Its a great read, sure to entertain and enlighten. It saved my bacon a few times when mdadm switched to the new metadata format. Once I began to learn about what the initramfs made possible, entire new worlds of possibility appeared (and I was not even on drugs!). It's actually something of a surprise to me that there are people upset about this change, since it cleans things up a bit while also giving people that want and/or need it, a great deal of power and control over the boot process that was not nearly as easy before. I do believe Gentoo, as a community/volunteer-run and super-power-user distribution, should be careful, a bit wary, and seriously consider the decisions made by our corporate colleagues (we do have the mandate to maintain our independence). However, simply because RHEL, SUSE, etc are corporation controlled distributions does not mean they are bad or trying to control/ruin the rest of the distros. Anyway, I merely thought I would place my commentary on this situation here for posterity. Since I have an opinion, I thought I would share it for better or worse. -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, 14 Mar 2012 08:22:09 -0700 Greg KH wrote: > The people doing the work today do understand them, by virtue of > doing the work involved, which gives them the say in how it is done. > That's how open source works, why is this ever a surprise to people? The problem is that when a small number of people who have commit access to core projects screw everything up and don't fix the mess they're inflicting upon everyone, the only option left with "how open source works" is for someone to fork the code from the point where it all worked. That isn't something that should be done lightly. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 03:08:27PM +, Ciaran McCreesh wrote: > On Wed, 14 Mar 2012 08:04:31 -0700 > Greg KH wrote: > > Not always, no, it isn't obvious that something didn't start up > > correctly, or that it didn't fully load properly. Some programs later > > on recover and handle things better. > > So why not work on fixing those things, since they're clearly symptoms > of a larger "oops, we have too much coupling" problem, instead of > forcing a workaround onto large numbers of users? I seriously doubt there are a "large number" of users here that have this issue. And even if there is, again, there is a simple solution that Gentoo provides for this issue, see the earlier initrd solution that we support today. As for "fixing this", see the oft-linked webpage as to why it can't be fixed easily, if at all, and honestly, I don't think it needs to be fixed. Especially as NO ONE has ever stepped up to fix these issues, which proves that no one is really invested in it. As for "too much coupling", you are talking to the wrong person. Personally, I feel we are too lightly coupled, and need to have stronger links happening here in order to properly solve the problems that we have in this area. If you disagree with the coupling issue, fine, but again, you need to do the work, and properly understand the issues involved. The people doing the work today do understand them, by virtue of doing the work involved, which gives them the say in how it is done. That's how open source works, why is this ever a surprise to people? I'll go back to lurking now, and getting stuff done, like everyone else on this thread should be doing, instead of complaining (this is -dev, not -users...) greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, 14 Mar 2012 08:04:31 -0700 Greg KH wrote: > Not always, no, it isn't obvious that something didn't start up > correctly, or that it didn't fully load properly. Some programs later > on recover and handle things better. So why not work on fixing those things, since they're clearly symptoms of a larger "oops, we have too much coupling" problem, instead of forcing a workaround onto large numbers of users? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 10:51:44AM -0400, Philip Webb wrote: > 120314 Greg KH wrote: > > if you have /usr on a different filesystem today, with no initrd, > > your machine could be broken and you don't even know it. > > Whatever do you mean ? -- if it were truly broken, > it wouldn't perform in some important & obvious respect. Not always, no, it isn't obvious that something didn't start up correctly, or that it didn't fully load properly. Some programs later on recover and handle things better. > Do you mean "insecure" ? -- if so, what is the threat ? No threat. > > greg "why is this thread still alive" k-h > > Your dismissive response is perhaps one reason ... Given that this is the first time I've responded to this thread in weeks, I doubt it. People like to complain, that's nothing new, I should be used to it by now, so perhaps it is all my fault... greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
120314 Greg KH wrote: > if you have /usr on a different filesystem today, with no initrd, > your machine could be broken and you don't even know it. Whatever do you mean ? -- if it were truly broken, it wouldn't perform in some important & obvious respect. Do you mean "insecure" ? -- if so, what is the threat ? > greg "why is this thread still alive" k-h Your dismissive response is perhaps one reason ... -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 08:40:46AM -0400, Joshua Kinard wrote: > I chose to stick with Gentoo as my distro of choice because I didn't like > the way Red Hat did things years ago. As well as a few other nitpicks I > have. It bugs me to no end that, despite running a fairly vanilla setup on > a source-based distro whose original inspiration came from BSD ports, I am > still affected by a decision made by RH. It is not a decision made by RH, some of the developers involved just happen to work for that distro. Others of us do not. Please don't get this confused with distro specific politics, it's not that at all. And again, if you have /usr on a different filesystem today, with no initrd, your machine could be broken and you don't even know it. greg "why is this thread still alive" k-h
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Tue, Mar 13, 2012 at 8:29 PM, Joshua Kinard wrote: > > My contention is that I shouldn't need an initramfs loaded into my kernel to > get my system into a minimally-usable state. I've been running separate > /usr setups for 10+ years, and only now, such a setup breaks, hence my beef > with Fedora's assertion that such a setup is wrong. I was thinking about this and here is another way to think about it. Right now you can't boot a linux kernel without a whole bunch of c/asm code in linux. That code is necessary to do arch-specific setup, locate the root device, mount it, and run init. The new model is that you can't boot a linux kernel without a whole bunch of c/asm code in linux, and a bunch of scripts and userspace code in a blob (that can potentially be part of the kernel image). You could view this as a simple refactoring of code. Instead of all the boot logic being in c/asm which is hard to tweak, now some of it is written in bash and a bunch of userspace tools. All of this can just be viewed as part of the kernel - it can even be part of the same file if you want. Obviously this isn't a perfect analogy, as a bunch of userspace tools already existed but now require the extra glue code to work (mounting /usr). Once upon a time you didn't even need grub or lilo to boot - you could just stick the kernel at the start of your boot disk and the first 512 bytes of the kernel conveniently contained a boot sector. That code actually still exists but simply tells the user to bugger_off. So, you really could just view this as another step in the evolution of the linux boot process. After seeing some of the more exotic boot processes used in ARM/etc stuff like this just doesn't throw me for much of a loop. And, if you setup dracut/genkernel appropriately it really is just one extra step to make your system bootable. Rich
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 04:39, Duncan wrote: > > THAT is why they're moving /bin, /sbin and /lib to /usr rather than the > other direction. rootfs will be ONLY a mountpoint, with even /etc/ being > bind-mounted from /usr/etc, and all system data unified on /usr, > including /etc. > > Viewed from that perspective, the direction of the "unification", > everything formerly on rootfs moving to /usr, so rootfs' only function is > providing the mountpoints for everything else, has a certain logic to > it... From one perspective, this makes sense. It actually is a kinda of holy grail for administrators, because it's one less filesystem to worry about backing up. > And they don't care about non-initr* based systems any more than they > care about non-Linux systems or for that matter, non-systemd Linux > systems. That's outside their operational universe. Other people are > welcome to continue working with "legacy" systems if they want, but Linux- > only, systemd-based, initr*-based systems are the only thing they're > interested in supporting, themselves. You know, I would have no problem with this if it wasn't a decision made by a single Linux distro with a huge amount of clout in the Linux world. This isn't like Debian forking Firefox into Ice Weasel, an issue that largely remains Debian-specific to this day. This is a change that will fundamentally alter the way every distro does things, and none of us (as far as I know) were given a choice in the matter. The /usr move is going to happen. I, along with a lot of other people, are going to have to "fix" all my installed systems over this. Not because of a choice made by all distros, but because one distro thinks that its way is the RightWay() and the OnlyWay(). That's what I disagree with. We shouldn't be affected by this change. Only Fedora users should have to deal with it. But other upstream projects are going to follow in Fedora's lead, and this brings us up to a decision point: adapt, or become irrelevant. I chose to stick with Gentoo as my distro of choice because I didn't like the way Red Hat did things years ago. As well as a few other nitpicks I have. It bugs me to no end that, despite running a fairly vanilla setup on a source-based distro whose original inspiration came from BSD ports, I am still affected by a decision made by RH. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On 03/14/2012 04:03, Duncan wrote: > > Bluez is a critical system service if that's your keyboard and you need > to do init-diagnostics. Dbus isn't... yet... but it's likely to be, for > some people at least, within a couple years, as systemd's going to be > using it, and other init services will assume/require it before /they/ > come up. Ah, bluetooth keyboards. The luddite in me finds those quite the oddity. I still use only PS/2, specifically because it's less complex and less likely to fail on me in a time of need. Or, put more comically: http://megatokyo.com/strip/305 -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
> "MS" == Marc Schiffbauer writes: MS> IIRC usr = unified system resources (not an abbrev. for "user") Nope. It is in fact for user. Before sysv created /home, bsd used /usr for user dirs. /usr/bin et all came later. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] New eclass proposal: chromium.eclass
On 3/11/12 6:27 PM, Mike Gilbert wrote: > I moved some of the functions currently implemented in the ebuilds for > www-client/chromium and www-client/google-chrome into a new eclass > "chromium.eclass". LGTM (Looks Good To Me). It seems no one else commented on this one, so I'm totally fine with checking this in. Thanks! signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
Joshua Kinard posted on Tue, 13 Mar 2012 20:16:10 -0400 as excerpted: > On 03/13/2012 07:54, James Broadhead wrote: > >> I believe that the Art of Unix Programming* says that /usr was the >> result of the original UNIX 4MB hard disk becoming full, and that they >> chose /usr to mount a second one. Every definition since then has been >> an attempt to justify preserving the split. > > Sounds like how a lot of UNIXy things came into being. This is why I > think /usr should be merged back into /, not the other way around. > Although, both approaches essentially achieve the same effect in the > end, once you move /etc and a few other bits, then point the kernel at > "/usr". I've seen it pointed out that in initr* based systems anyway, the "new" rootfs is effectively taking the role the old initrd tmproot did, it's only there in a bootstrapping role, no "running system" content at all, except that instead of using pivot_root or whatever to get off it once the system early bootstrap is done, it remains the mountpoint used by everything else on the running system. That's rootfs's only modern role, according to these folks, providing the mountpoints for everything else. And with an assumed initr* based setup, it all "just works". Rootfs can in fact be entirely virtual, tmpfs or squashfs or whatever, setup only in the initr*, with only a few minimal early-boot config files, the modules necessary to boot the rest of the system, etc, as content, and those quickly over-mounted with the "real" system -- note that /usr/etc can be bind-mounted over the boot-time-stub /etc too, so literally, post-initr*, the ONLY part of rootfs operationally visible is the mountpoints used by everything else. THAT is why they're moving /bin, /sbin and /lib to /usr rather than the other direction. rootfs will be ONLY a mountpoint, with even /etc/ being bind-mounted from /usr/etc, and all system data unified on /usr, including /etc. Viewed from that perspective, the direction of the "unification", everything formerly on rootfs moving to /usr, so rootfs' only function is providing the mountpoints for everything else, has a certain logic to it... And they don't care about non-initr* based systems any more than they care about non-Linux systems or for that matter, non-systemd Linux systems. That's outside their operational universe. Other people are welcome to continue working with "legacy" systems if they want, but Linux- only, systemd-based, initr*-based systems are the only thing they're interested in supporting, themselves. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: newsitem: unmasking udev-181
Joshua Kinard posted on Tue, 13 Mar 2012 20:13:53 -0400 as excerpted: > On 03/13/2012 01:11, Luca Barbato wrote: > >> Our current init system doesn't have any problem with /usr being >> mounted later, but udev might have issues. >> >> Same could be said about bluez and dbus. > > bluez and dbus aren't system-critical services, however. udev kinda is, > along with key filesystem tools. Bluez is a critical system service if that's your keyboard and you need to do init-diagnostics. Dbus isn't... yet... but it's likely to be, for some people at least, within a couple years, as systemd's going to be using it, and other init services will assume/require it before /they/ come up. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
