On Thu, Sep 8, 2011 at 1:01 PM, Michael Schreckenbauer <grim...@gmx.de> wrote: > Am Donnerstag, 8. September 2011, 12:34:50 schrieb Canek Peláez Valdés: >> On Thu, Sep 8, 2011 at 12:06 PM, Michael Schreckenbauer <grim...@gmx.de> > wrote: >> > Am Donnerstag, 8. September 2011, 11:13:58 schrieb Canek Peláez Valdés: >> >> On Thu, Sep 8, 2011 at 4:09 AM, Michael Schreckenbauer >> >> <grim...@gmx.de> >> > >> > wrote: >> >> > Am Mittwoch, 7. September 2011, 23:33:35 schrieb Canek Peláez Valdés: >> >> >> I don't see any problem with an initramfs larger than the >> >> >> kernel. It >> >> >> will handle a lot of stuff. But if you don't want to change your >> >> >> /boot partition, then don't upgrade to new kernels. >> >> > >> >> > How about accepting the fact, that there are a lot of things out >> >> > there >> >> > "you don't see"? Get over it. People have told a lot of valid >> >> > reasons. >> >> > They might not seem valid to you, but that's not their problem. >> >> >> >> Relax man, I keep saying that is *I* who don't see a valid reason. >> >> That doesn't mean there is no valid reason; I thought that went >> >> without saying. Sorry if it sounded like I was invalidating all you >> >> guys reasons. >> >> >> >> My primary point was that, I *you* have your reasons to keep a >> >> separated /usr, then by all means do it. You will only need an >> >> initramfs. >> > >> > That's the point. You *need* an initramfs. You know KISS? >> >> If it's so "simple", write the code for support the option of not >> having an initramfs. If it's not that simple, then what KISS are we >> talking about? > > We already *have* the situation of not requiring initramfs for separate /usr. > Mission accomplished. > It's the upcoming change, that violates KISS. If udev cannot work properly > with separate /usr, fix udev not the FS-hierarchy. What next? Put /home into > initramfs, because udev decides it cannot work without /home mounted?
Then don't upgrade. Keep doing only security updates. Want the new cool stuff? Roll with the change. >> >> > Have you *ever* thought about machines, that are not x86 or >> >> > x86_64? >> >> > Here's an intersting read: >> >> > http://permalink.gmane.org/gmane.linux.gentoo.devel/72769 >> >> >> >> No, I haven't thought about them, because I don't use them. What it >> >> has to do with anything? >> > >> > Well, I linked a mail. MIPS is mentioned. As I read it, there are cases >> > with MIPS, where the initramfs *has* to be built into the kernel *and* >> > the kernel- image is size restricted. That's the problem with an >> > initramfs bigger than the kernel itself. >> >> That's a MIPS restriction. Then with MIPS you will need to put /usr in >> /, and problem solved. > > Solved? You call "no separate /usr on MIPS" a solution? > How about existing installations? Ah, yes, don't upgrade. There you go. >> But no, everyone wants everything, and exactly >> the way they want. > > It works now. Exactly, and if you don't upgrade, it will work as long as you want. >> Well, then they will need to write the code to support it, because no >> developer is forced to support every single architecture in the whole >> damn world, in every possible configuration available. >> >> >> >> Change happens. >> >> > >> >> > That's right. And sometimes these changes are simply bad ideas. >> >> >> >> If so you think, then write the code to support the *really good* >> >> ideas. >> > >> > Ah. Criticism is only allowed, if you are writing the code. Not in my >> > world, sorry. >> >> By all means, criticize as much as you want. What I meant by "If so >> you think, then write the code to support the *really good* ideas" is >> that you have the *option* to do that. You can of course complain >> forever: that will not mean that anybody (and in particular the >> developers) will listen. > > Not listening to users is a very bad idea. No, they listen to users. They just don't listen too every user, because that's impossible. Maybe I'm wrong, but I think your setup is in the minority of use-cases. Who they should listen to? >> Of course not. But, as with anything Open Source related, the ones >> that write the support code will prevail. The complainers (if they >> only complain) will not change anything. > > You keep talking about "complainers". If someone complains and doesn't code, it's a complainer. By definition. If someone complains and code, it's creating alternative technologies. > I'd say, we discuss things, as do the > gentoo-devs on their list. I agree. I'm subscribed to both. >> My point is: if everything would be the other way around, and the >> Gentoo (or kernel, or udev) developers decided that the True One Way >> (TM) to do things were to separate / and /usr, I would do it. I did it >> when me moved from ipchains to iptables, and that was particularly >> painful because every single damn script just stopped working. > > Ah yes. What option was lost, when this switch happend? > Nobody (I think) complains about some config changes. It's the removal of sane > and valid options. You cannot keep *EVERY* option supported. It's impossible. They grow a lot really fast. You have to mark some things as "not supported". Don't like it? Try alternative technologies. >> But such is life: i didn't write the code. If I wanted to keep up with >> development, I needed to change my way of doing things. I have rolled >> with the change every single time since I started to use Linux in 1996 >> (damn, I'm old), and sometimes it bite you in the ass in the long run >> (hello HAL!) >> >> But most of the times is for a good reason, and everything kinda >> improves. And since I'm not writing code, just taking advantage of >> getting it for free (as in beer and as in speech), I usually trust >> developers. It usually pays off. > > How's needing an initramsfs for separate /usr an improvement? With the initramfs you can do a lot of really cool stuff. I know it's shallow, but I really like my plymouth-based splash screen. >> Of course, sometimes it doesn't (hello devfs!), but what are you going >> to do? Look a gift horse in the mouth? >> >> In the long term, trusting the developers usually it's the way to go. >> Been here a long time, I stick to my guns. Don't like it? Well, >> complain if you want, but if you don't writing some code it would >> probably be for nothing. > > Yeah, "probably", that's why we discuss things. Again, we can discuss (or complain) until the sun is red. As long as we don't give code back, it's basically academic. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
